Merge tag 'docs-4.15-2' of git://git.lwn.net/linux

			instead using the legacy FADT method

	profile=	[KNL] Enable kernel profiling via /proc/profile

			Format: [schedule,]<number>

			Format: [<profiletype>,]<number>

			Param: <profiletype>: "schedule", "sleep", or "kvm"

				[defaults to kernel profiling]

			Param: "schedule" - profile schedule points.

			Param: <number> - step/bucket size as a power of 2 for

				statistical time based profiling.

			Param: "sleep" - profile D-state sleeping (millisecs).

				Requires CONFIG_SCHEDSTATS

			Param: "kvm" - profile VM exits.

			Param: <number> - step/bucket size as a power of 2 for

				statistical time based profiling.

	prompt_ramdisk=	[RAM] List of RAM disks to prompt for floppy disk

			before loading.

   which can be found in Documentation/process/submitting-patches.rst.  Code without a

   proper signoff cannot be merged into the mainline.

 - Co-Developed-by: states that the patch was also created by another developer

   along with the original author.  This is useful at times when multiple

   people work on a single patch.  Note, this person also needs to have a

   Signed-off-by: line in the patch as well.

 - Acked-by: indicates an agreement by another developer (often a

   maintainer of the relevant code) that the patch is appropriate for

   inclusion into the kernel.

<name-of-detected-video-adapter> tells what video adapter did Linux detect

-- it's either a generic adapter name (MDA, CGA, HGC, EGA, VGA, VESA VGA [a VGA

with VESA-compliant BIOS]) or a chipset name (e.g., Trident). Direct detection

of chipsets is turned off by default (see CONFIG_VIDEO_SVGA in chapter 4 to see

how to enable it if you really want) as it's inherently unreliable due to

of chipsets is turned off by default as it's inherently unreliable due to

absolutely insane PC design.

"0  0F00  80x25" means that the first menu item (the menu items are numbered

	0x0f05	VGA 80x30 (480 scans, 16-point font)

	0x0f06	VGA 80x34 (480 scans, 14-point font)

	0x0f07	VGA 80x60 (480 scans, 8-point font)

	0x0f08	Graphics hack (see the CONFIG_VIDEO_HACK paragraph below)

	0x0f08	Graphics hack (see the VIDEO_GFX_HACK paragraph below)

   0x1000 to 0x7fff - modes specified by resolution. The code has a "0xRRCC"

	form where RR is a number of rows and CC is a number of columns.

Options

~~~~~~~

Some options can be set in the source text (in arch/i386/boot/video.S).

All of them are simple #define's -- change them to #undef's when you want to

switch them off. Currently supported:

CONFIG_VIDEO_SVGA - enables autodetection of SVGA cards. This is switched

off by default as it's a bit unreliable due to terribly bad PC design. If you

really want to have the adapter autodetected (maybe in case the ``scan`` feature

doesn't work on your machine), switch this on and don't cry if the results

are not completely sane. In case you really need this feature, please drop me

a mail as I think of removing it some day.

CONFIG_VIDEO_VESA - enables autodetection of VESA modes. If it doesn't work

on your machine (or displays a "Error: Scanning of VESA modes failed" message),

you can switch it off and report as a bug.

CONFIG_VIDEO_COMPACT - enables compacting of the video mode list. If there

are more modes with the same screen size, only the first one is kept (see above

for more info on mode ordering). However, in very strange cases it's possible

that the first "version" of the mode doesn't work although some of the others

do -- in this case turn this switch off to see the rest.

CONFIG_VIDEO_RETAIN - enables retaining of screen contents when switching

video modes. Works only with some boot loaders which leave enough room for the

buffer. (If you have old LILO, you can adjust heap_end_ptr and loadflags

in setup.S, but it's better to upgrade the boot loader...)

CONFIG_VIDEO_LOCAL - enables inclusion of "local modes" in the list. The

local modes are added automatically to the beginning of the list not depending

on hardware configuration. The local modes are listed in the source text after

the "local_mode_table:" line. The comment before this line describes the format

of the table (which also includes a video card name to be displayed on the

top of the menu).

CONFIG_VIDEO_400_HACK - force setting of 400 scan lines for standard VGA

modes. This option is intended to be used on certain buggy BIOSes which draw

some useless logo using font download and then fail to reset the correct mode.

Don't use unless needed as it forces resetting the video card.

CONFIG_VIDEO_GFX_HACK - includes special hack for setting of graphics modes

to be used later by special drivers (e.g., 800x600 on IBM ThinkPad -- see

ftp://ftp.phys.keio.ac.jp/pub/XFree86/800x600/XF86Configs/XF86Config.IBM_TP560).

Build options for arch/x86/boot/* are selected by the kernel kconfig

utility and the kernel .config file.

VIDEO_GFX_HACK - includes special hack for setting of graphics modes

to be used later by special drivers.

Allows to set _any_ BIOS mode including graphic ones and forcing specific

text screen resolution instead of peeking it from BIOS variables. Don't use

unless you think you know what you're doing. To activate this setup, use

mode number 0x0f08 (see section 3).

mode number 0x0f08 (see the Mode IDs section above).

Still doesn't work?

~~~~~~~~~~~~~~~~~~~

When the mode detection doesn't work (e.g., the mode list is incorrect or

the machine hangs instead of displaying the menu), try to switch off some of

the configuration options listed in section 4. If it fails, you can still use

the configuration options listed under "Options". If it fails, you can still use

your kernel with the video mode set directly via the kernel parameter.

In either case, please send me a bug report containing what _exactly_

end setting". Adding 0x8000 to the mode ID might fix the problem. Unfortunately,

this must be done manually -- no autodetection mechanisms are available.

If you have a VGA card and your display still looks as on EGA, your BIOS

is probably broken and you need to set the CONFIG_VIDEO_400_HACK switch to

force setting of the correct mode.

History

~~~~~~~

     - SMP 배리어 짝맞추기.

     - 메모리 배리어 시퀀스의 예.

     - 읽기 메모리 배리어 vs 로드 예측.

     - 이행성

     - Multicopy 원자성.

 (*) 명시적 커널 배리어.

해줍니다.

데이터 의존성에 의해 제공되는 이 순서규칙은 이를 포함하고 있는 CPU 에

지역적임을 알아두시기 바랍니다.  더 많은 정보를 위해선 "Multicopy 원자성"

섹션을 참고하세요.

데이터 의존성 배리어는 매우 중요한데, 예를 들어 RCU 시스템에서 그렇습니다.

include/linux/rcupdate.h 의 rcu_assign_pointer() 와 rcu_dereference() 를

참고하세요.  여기서 데이터 의존성 배리어는 RCU 로 관리되는 포인터의 타겟을 현재

주어진 if 문의 then 절과 else 절에게만 (그리고 이 두 절 내에서 호출되는

함수들에게까지) 적용되지, 이 if 문을 뒤따르는 코드에는 적용되지 않습니다.

마지막으로, 컨트롤 의존성은 이행성 (transitivity) 을 제공하지 -않습니다-.  이건

'x' 와 'y' 가 둘 다 0 이라는 초기값을 가졌다는 가정 하의 두개의 예제로

보이겠습니다:

	CPU 0                     CPU 1

	=======================   =======================

	r1 = READ_ONCE(x);        r2 = READ_ONCE(y);

	if (r1 > 0)               if (r2 > 0)

	  WRITE_ONCE(y, 1);         WRITE_ONCE(x, 1);

	assert(!(r1 == 1 && r2 == 1));

이 두 CPU 예제에서 assert() 의 조건은 항상 참일 것입니다.  그리고, 만약 컨트롤

의존성이 이행성을 (실제로는 그러지 않지만) 보장한다면, 다음의 CPU 가 추가되어도

아래의 assert() 조건은 참이 될것입니다:

컨트롤 의존성에 의해 제공되는 이 순서규칙은 이를 포함하고 있는 CPU 에

지역적입니다.  더 많은 정보를 위해선 "Multicopy 원자성" 섹션을 참고하세요.

	CPU 2

	=====================

	WRITE_ONCE(x, 2);

	assert(!(r1 == 2 && r2 == 1 && x == 2)); /* FAILS!!! */

하지만 컨트롤 의존성은 이행성을 제공하지 -않기- 때문에, 세개의 CPU 예제가 실행

완료된 후에 위의 assert() 의 조건은 거짓으로 평가될 수 있습니다.  세개의 CPU

예제가 순서를 지키길 원한다면, CPU 0 와 CPU 1 코드의 로드와 스토어 사이, "if"

문 바로 다음에 smp_mb()를 넣어야 합니다.  더 나아가서, 최초의 두 CPU 예제는

매우 위험하므로 사용되지 않아야 합니다.

이 두개의 예제는 다음 논문:

http://www.cl.cam.ac.uk/users/pes20/ppc-supplemental/test6.pdf 와

이 사이트: https://www.cl.cam.ac.uk/~pes20/ppcmem/index.html 에 나온 LB 와 WWC

리트머스 테스트입니다.

요약하자면:

  (*) 컨트롤 의존성은 보통 다른 타입의 배리어들과 짝을 맞춰 사용됩니다.

  (*) 컨트롤 의존성은 이행성을 제공하지 -않습니다-.  이행성이 필요하다면,

      smp_mb() 를 사용하세요.

  (*) 컨트롤 의존성은 multicopy 원자성을 제공하지 -않습니다-.  모든 CPU 들이

      특정 스토어를 동시에 보길 원한다면, smp_mb() 를 사용하세요.

  (*) 컴파일러는 컨트롤 의존성을 이해하고 있지 않습니다.  따라서 컴파일러가

      여러분의 코드를 망가뜨리지 않도록 하는건 여러분이 해야 하는 일입니다.

CPU 간 상호작용을 다룰 때에 일부 타입의 메모리 배리어는 항상 짝을 맞춰

사용되어야 합니다.  적절하게 짝을 맞추지 않은 코드는 사실상 에러에 가깝습니다.

범용 배리어들은 범용 배리어끼리도 짝을 맞추지만 이행성이 없는 대부분의 다른

타입의 배리어들과도 짝을 맞춥니다.  ACQUIRE 배리어는 RELEASE 배리어와 짝을

맞춥니다만, 둘 다 범용 배리어를 포함해 다른 배리어들과도 짝을 맞출 수 있습니다.

쓰기 배리어는 데이터 의존성 배리어나 컨트롤 의존성, ACQUIRE 배리어, RELEASE

배리어, 읽기 배리어, 또는 범용 배리어와 짝을 맞춥니다.  비슷하게 읽기 배리어나

컨트롤 의존성, 또는 데이터 의존성 배리어는 쓰기 배리어나 ACQUIRE 배리어,

RELEASE 배리어, 또는 범용 배리어와 짝을 맞추는데, 다음과 같습니다:

범용 배리어들은 범용 배리어끼리도 짝을 맞추지만 multicopy 원자성이 없는

대부분의 다른 타입의 배리어들과도 짝을 맞춥니다.  ACQUIRE 배리어는 RELEASE

배리어와 짝을 맞춥니다만, 둘 다 범용 배리어를 포함해 다른 배리어들과도 짝을

맞출 수 있습니다.  쓰기 배리어는 데이터 의존성 배리어나 컨트롤 의존성, ACQUIRE

배리어, RELEASE 배리어, 읽기 배리어, 또는 범용 배리어와 짝을 맞춥니다.

비슷하게 읽기 배리어나 컨트롤 의존성, 또는 데이터 의존성 배리어는 쓰기 배리어나

ACQUIRE 배리어, RELEASE 배리어, 또는 범용 배리어와 짝을 맞추는데, 다음과

같습니다:

	CPU 1		      CPU 2

	===============	      ===============

	===============	      ===============================

	r1 = READ_ONCE(y);

	<범용 배리어>

	WRITE_ONCE(y, 1);     if (r2 = READ_ONCE(x)) {

	WRITE_ONCE(x, 1);     if (r2 = READ_ONCE(x)) {

			         <묵시적 컨트롤 의존성>

			         WRITE_ONCE(y, 1);

			      }

	                                        :       :       +-------+

이행성

------

MULTICOPY 원자성

----------------

Multicopy 원자성은 실제의 컴퓨터 시스템에서 항상 제공되지는 않는, 순서 맞추기에

대한 상당히 직관적인 개념으로, 특정 스토어가 모든 CPU 들에게 동시에 보여지게

됨을, 달리 말하자면 모든 CPU 들이 모든 스토어들이 보여지는 순서를 동의하게 되는

것입니다.  하지만, 완전한 multicopy 원자성의 사용은 가치있는 하드웨어

최적화들을 무능하게 만들어버릴 수 있어서, 보다 완화된 형태의 ``다른 multicopy

원자성'' 라는 이름의, 특정 스토어가 모든 -다른- CPU 들에게는 동시에 보여지게

하는 보장을 대신 제공합니다.  이 문서의 뒷부분들은 이 완화된 형태에 대해 논하게

됩니다만, 단순히 ``multicopy 원자성'' 이라고 부르겠습니다.

이행성(transitivity)은 실제의 컴퓨터 시스템에서 항상 제공되지는 않는, 순서

맞추기에 대한 상당히 직관적인 개념입니다.  다음의 예가 이행성을 보여줍니다:

다음의 예가 multicopy 원자성을 보입니다:

	CPU 1			CPU 2			CPU 3

	=======================	=======================	=======================

		{ X = 0, Y = 0 }

	STORE X=1		LOAD X			STORE Y=1

				<범용 배리어>		<범용 배리어>

				LOAD Y			LOAD X

CPU 2 의 X 로드가 1을 리턴했고 Y 로드가 0을 리턴했다고 해봅시다.  이는 CPU 2 의

X 로드가 CPU 1 의 X 스토어 뒤에 이루어졌고 CPU 2 의 Y 로드는 CPU 3 의 Y 스토어

전에 이루어졌음을 의미합니다.  그럼 "CPU 3 의 X 로드는 0을 리턴할 수 있나요?"

CPU 2 의 X 로드는 CPU 1 의 스토어 후에 이루어졌으니, CPU 3 의 X 로드는 1을

리턴하는게 자연스럽습니다.  이런 생각이 이행성의 한 예입니다: CPU A 에서 실행된

로드가 CPU B 에서의 같은 변수에 대한 로드를 뒤따른다면, CPU A 의 로드는 CPU B

의 로드가 내놓은 값과 같거나 그 후의 값을 내놓아야 합니다.

리눅스 커널에서 범용 배리어의 사용은 이행성을 보장합니다.  따라서, 앞의 예에서

CPU 2 의 X 로드가 1을, Y 로드는 0을 리턴했다면, CPU 3 의 X 로드는 반드시 1을

리턴합니다.

하지만, 읽기나 쓰기 배리어에 대해서는 이행성이 보장되지 -않습니다-.  예를 들어,

앞의 예에서 CPU 2 의 범용 배리어가 아래처럼 읽기 배리어로 바뀐 경우를 생각해

봅시다:

	STORE X=1		r1=LOAD X (reads 1)	LOAD Y (reads 1)

				<범용 배리어>		<읽기 배리어>

				STORE Y=r1		LOAD X

CPU 2 의 Y 로의 스토어에 사용되는 X 로드의 결과가 1 이었고 CPU 3 의 Y 로드가

1을 리턴했다고 해봅시다.  이는 CPU 1 의 X 로의 스토어가 CPU 2 의 X 로부터의

로드를 앞서고 CPU 2 의 Y 로의 스토어가 CPU 3 의 Y 로부터의 로드를 앞섬을

의미합니다.  또한, 여기서의 메모리 배리어들은 CPU 2 가 자신의 로드를 자신의

스토어 전에 수행하고, CPU 3 가 Y 로부터의 로드를 X 로부터의 로드 전에 수행함을

보장합니다.  그럼 "CPU 3 의 X 로부터의 로드는 0 을 리턴할 수 있을까요?"

CPU 3 의 X 로드가 CPU 2 의 로드보다 뒤에 이루어졌으므로, CPU 3 의 X 로부터의

로드는 1 을 리턴한다고 예상하는게 당연합니다.  이런 예상은 multicopy

원자성으로부터 나옵니다: CPU B 에서 수행된 로드가 CPU A 의 같은 변수로부터의

로드를 뒤따른다면 (그리고 CPU A 가 자신이 읽은 값으로 먼저 해당 변수에 스토어

하지 않았다면) multicopy 원자성을 제공하는 시스템에서는, CPU B 의 로드가 CPU A

의 로드와 같은 값 또는 그 나중 값을 리턴해야만 합니다.  하지만, 리눅스 커널은

시스템들이 multicopy 원자성을 제공할 것을 요구하지 않습니다.

앞의 범용 메모리 배리어의 사용은 모든 multicopy 원자성의 부족을 보상해줍니다.

앞의 예에서, CPU 2 의 X 로부터의 로드가 1 을 리턴했고 CPU 3 의 Y 로부터의

로드가 1 을 리턴했다면, CPU 3 의 X 로부터의 로드는 1을 리턴해야만 합니다.

하지만, 의존성, 읽기 배리어, 쓰기 배리어는 항상 non-multicopy 원자성을 보상해

주지는 않습니다.  예를 들어, CPU 2 의 범용 배리어가 앞의 예에서 사라져서

아래처럼 데이터 의존성만 남게 되었다고 해봅시다:

	CPU 1			CPU 2			CPU 3

	=======================	=======================	=======================

		{ X = 0, Y = 0 }

	STORE X=1		LOAD X			STORE Y=1

				<읽기 배리어>		<범용 배리어>

				LOAD Y			LOAD X

이 코드는 이행성을 갖지 않습니다: 이 예에서는, CPU 2 의 X 로드가 1을

리턴하고, Y 로드는 0을 리턴하지만 CPU 3 의 X 로드가 0을 리턴하는 것도 완전히

합법적입니다.

CPU 2 의 읽기 배리어가 자신의 읽기는 순서를 맞춰줘도, CPU 1 의 스토어와의

순서를 맞춰준다고는 보장할 수 없다는게 핵심입니다.  따라서, CPU 1 과 CPU 2 가

버퍼나 캐시를 공유하는 시스템에서 이 예제 코드가 실행된다면, CPU 2 는 CPU 1 이

쓴 값에 좀 빨리 접근할 수 있을 것입니다.  따라서 CPU 1 과 CPU 2 의 접근으로

조합된 순서를 모든 CPU 가 동의할 수 있도록 하기 위해 범용 배리어가 필요합니다.

범용 배리어는 "글로벌 이행성"을 제공해서, 모든 CPU 들이 오퍼레이션들의 순서에

동의하게 할 것입니다.  반면, release-acquire 조합은 "로컬 이행성" 만을

제공해서, 해당 조합이 사용된 CPU 들만이 해당 액세스들의 조합된 순서에 동의함이

보장됩니다.  예를 들어, 존경스런 Herman Hollerith 의 C 코드로 보면:

	STORE X=1		r1=LOAD X (reads 1)	LOAD Y (reads 1)

				<데이터 의존성>		<읽기 배리어>

				STORE Y=r1		LOAD X (reads 0)

이 변화는 non-multicopy 원자성이 만연하게 합니다: 이 예에서, CPU 2 의 X

로부터의 로드가 1을 리턴하고, CPU 3 의 Y 로부터의 로드가 1 을 리턴하는데, CPU 3

의 X 로부터의 로드가 0 을 리턴하는게 완전히 합법적입니다.

핵심은, CPU 2 의 데이터 의존성이 자신의 로드와 스토어를 순서짓지만, CPU 1 의

스토어에 대한 순서는 보장하지 않는다는 것입니다.  따라서, 이 예제가 CPU 1 과

CPU 2 가 스토어 버퍼나 한 수준의 캐시를 공유하는, multicopy 원자성을 제공하지

않는 시스템에서 수행된다면 CPU 2 는 CPU 1 의 쓰기에 이른 접근을 할 수도

있습니다.  따라서, 모든 CPU 들이 여러 접근들의 조합된 순서에 대해서 동의하게

하기 위해서는 범용 배리어가 필요합니다.

범용 배리어는 non-multicopy 원자성만 보상할 수 있는게 아니라, -모든- CPU 들이

-모든- 오퍼레이션들의 순서를 동일하게 인식하게 하는 추가적인 순서 보장을

만들어냅니다.  반대로, release-acquire 짝의 연결은 이런 추가적인 순서는

제공하지 않는데, 해당 연결에 들어있는 CPU 들만이 메모리 접근의 조합된 순서에

대해 동의할 것으로 보장됨을 의미합니다.  예를 들어, 존경스런 Herman Hollerith

의 코드를 C 코드로 변환하면:

	int u, v, x, y, z;

	}

cpu0(), cpu1(), 그리고 cpu2() 는 smp_store_release()/smp_load_acquire() 쌍의

연결을 통한 로컬 이행성에 동참하고 있으므로, 다음과 같은 결과는 나오지 않을

겁니다:

연결에 참여되어 있으므로, 다음과 같은 결과는 나오지 않을 겁니다:

	r0 == 1 && r1 == 1 && r2 == 1

	r1 == 1 && r5 == 0

하지만, release-acquire 타동성은 동참한 CPU 들에만 적용되므로 cpu3() 에는

적용되지 않습니다.  따라서, 다음과 같은 결과가 가능합니다:

하지만, release-acquire 에 의해 제공되는 순서는 해당 연결에 동참한 CPU 들에만

적용되므로 cpu3() 에, 적어도 스토어들 외에는 적용되지 않습니다.  따라서, 다음과

같은 결과가 가능합니다:

	r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0

이런 결과는 어떤 것도 재배치 되지 않는, 순차적 일관성을 가진 가상의

시스템에서도 일어날 수 있음을 기억해 두시기 바랍니다.

다시 말하지만, 당신의 코드가 글로벌 이행성을 필요로 한다면, 범용 배리어를

사용하십시오.

다시 말하지만, 당신의 코드가 모든 오퍼레이션들의 완전한 순서를 필요로 한다면,

범용 배리어를 사용하십시오.

==================

	Chapter 7.1: Memory-Access Ordering

	Chapter 7.4: Buffering and Combining Memory Writes

ARM Architecture Reference Manual (ARMv8, for ARMv8-A architecture profile)

	Chapter B2: The AArch64 Application Level Memory Model

IA-32 Intel Architecture Software Developer's Manual, Volume 3:

System Programming Guide

	Chapter 7.1: Locked Atomic Operations

	Appendix D: Formal Specification of the Memory Models

	Appendix J: Programming with the Memory Models

Storage in the PowerPC (Stone and Fitzgerald)

UltraSPARC Programmer Reference Manual

	Chapter 5: Memory Accesses and Cacheability

	Chapter 15: Sparc-V9 Memory Models

  endif

endif

ifneq ($(KBUILD_ENABLE_EXTRA_GCC_CHECKS),)

  cmd_checkdoc = $(srctree)/scripts/kernel-doc -none $< ;

endif

# Do section mismatch analysis for each module/built-in.o

ifdef CONFIG_DEBUG_SECTION_MISMATCH

  cmd_secanalysis = ; scripts/mod/modpost $@

	$(call echo-cmd,checksrc) $(cmd_checksrc)			  \

	$(call cmd_and_fixdep,cc_o_c)					  \

	$(cmd_modversions_c)						  \

	$(cmd_checkdoc)							  \

	$(call echo-cmd,objtool) $(cmd_objtool)				  \

	$(call echo-cmd,record_mcount) $(cmd_record_mcount)

endef