Skip to content

Commit be834aa

Browse files
torvaldstorvalds
committed
Merge tag 'docs-4.11-fixes' of git://git.lwn.net/linux
Pull documentation fixes from Jonathan Corbet: "A few fixes for the docs tree, including one for a 4.11 build regression" * tag 'docs-4.11-fixes' of git://git.lwn.net/linux: Documentation/sphinx: fix primary_domain configuration docs: Fix htmldocs build failure doc/ko_KR/memory-barriers: Update control-dependencies section pcieaer doc: update the link Documentation: Update path to sysrq.txt
2 parents 91aff98 + fd5d666 commit be834aa

File tree

8 files changed

+47
-41
lines changed

8 files changed

+47
-41
lines changed

‎Documentation/DocBook/Makefile

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -7,12 +7,12 @@
77
# list of DOCBOOKS.
88

99
DOCBOOKS := z8530book.xml \
10-
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
10+
kernel-hacking.xml kernel-locking.xml \
1111
writing_usb_driver.xml networking.xml \
1212
kernel-api.xml filesystems.xml lsm.xml kgdb.xml \
1313
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
1414
genericirq.xml s390-drivers.xml scsi.xml \
15-
sh.xml regulator.xml w1.xml \
15+
sh.xml w1.xml \
1616
writing_musb_glue_layer.xml
1717

1818
ifeq ($(DOCBOOKS),)

‎Documentation/PCI/pcieaer-howto.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -256,7 +256,7 @@ After reboot with new kernel or insert the module, a device file named
256256

257257
Then, you need a user space tool named aer-inject, which can be gotten
258258
from:
259-
http://www.kernel.org/pub/linux/utils/pci/aer-inject/
259+
https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/
260260

261261
More information about aer-inject can be found in the document comes
262262
with its source code.

‎Documentation/conf.py

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -135,7 +135,7 @@
135135
# If true, `todo` and `todoList` produce output, else they produce nothing.
136136
todo_include_todos = False
137137

138-
primary_domain = 'C'
138+
primary_domain = 'c'
139139
highlight_language = 'none'
140140

141141
# -- Options for HTML output ----------------------------------------------

‎Documentation/media/v4l-drivers/bttv.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -312,7 +312,7 @@ information out of a register+stack dump printed by the kernel on
312312
protection faults (so-called "kernel oops").
313313

314314
If you run into some kind of deadlock, you can try to dump a call trace
315-
for each process using sysrq-t (see Documentation/sysrq.txt).
315+
for each process using sysrq-t (see Documentation/admin-guide/sysrq.rst).
316316
This way it is possible to figure where *exactly* some process in "D"
317317
state is stuck.
318318

‎Documentation/s390/Debugging390.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2116,7 +2116,7 @@ The sysrq key reading is very picky ( I have to type the keys in an
21162116
This is particularly useful for syncing disks unmounting & rebooting
21172117
if the machine gets partially hung.
21182118

2119-
Read Documentation/sysrq.txt for more info
2119+
Read Documentation/admin-guide/sysrq.rst for more info
21202120

21212121
References:
21222122
===========

‎Documentation/sysctl/kernel.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -85,7 +85,7 @@ show up in /proc/sys/kernel:
8585
- softlockup_all_cpu_backtrace
8686
- soft_watchdog
8787
- stop-a [ SPARC only ]
88-
- sysrq ==> Documentation/sysrq.txt
88+
- sysrq ==> Documentation/admin-guide/sysrq.rst
8989
- sysctl_writes_strict
9090
- tainted
9191
- threads-max

‎Documentation/translations/ko_KR/memory-barriers.txt

Lines changed: 37 additions & 31 deletions
Original file line numberDiff line numberDiff line change
@@ -662,6 +662,10 @@ include/linux/rcupdate.h 의 rcu_assign_pointer() 와 rcu_dereference() 를
662662
컨트롤 의존성
663663
-------------
664664

665+
현재의 컴파일러들은 컨트롤 의존성을 이해하고 있지 않기 때문에 컨트롤 의존성은
666+
약간 다루기 어려울 수 있습니다. 이 섹션의 목적은 여러분이 컴파일러의 무시로
667+
인해 여러분의 코드가 망가지는 걸 막을 수 있도록 돕는겁니다.
668+
665669
로드-로드 컨트롤 의존성은 데이터 의존성 배리어만으로는 정확히 동작할 수가
666670
없어서 읽기 메모리 배리어를 필요로 합니다. 아래의 코드를 봅시다:
667671

@@ -689,20 +693,21 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
689693

690694
q = READ_ONCE(a);
691695
if (q) {
692-
WRITE_ONCE(b, p);
696+
WRITE_ONCE(b, 1);
693697
}
694698

695699
컨트롤 의존성은 보통 다른 타입의 배리어들과 짝을 맞춰 사용됩니다. 그렇다곤
696-
하나, READ_ONCE() 는 반드시 사용해야 함을 부디 명심하세요! READ_ONCE() 가
697-
없다면, 컴파일러가 'a' 로부터의 로드를 'a' 로부터의 또다른 로드와, 'b' 로의
698-
스토어를 'b' 로의 또다른 스토어와 조합해 버려 매우 비직관적인 결과를 초래할 수
699-
있습니다.
700+
하나, READ_ONCE() 도 WRITE_ONCE() 도 선택사항이 아니라 필수사항임을 부디
701+
명심하세요! READ_ONCE() 가 없다면, 컴파일러는 'a' 로부터의 로드를 'a' 로부터의
702+
또다른 로드와 조합할 수 있습니다. WRITE_ONCE() 가 없다면, 컴파일러는 'b' 로의
703+
스토어를 'b' 로의 또라느 스토어들과 조합할 수 있습니다. 두 경우 모두 순서에
704+
있어 상당히 비직관적인 결과를 초래할 수 있습니다.
700705

701706
이걸로 끝이 아닌게, 컴파일러가 변수 'a' 의 값이 항상 0이 아니라고 증명할 수
702707
있다면, 앞의 예에서 "if" 문을 없애서 다음과 같이 최적화 할 수도 있습니다:
703708

704709
q = a;
705-
b = p; /* BUG: Compiler and CPU can both reorder!!! */
710+
b = 1; /* BUG: Compiler and CPU can both reorder!!! */
706711

707712
그러니 READ_ONCE() 를 반드시 사용하세요.
708713

@@ -712,11 +717,11 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
712717
q = READ_ONCE(a);
713718
if (q) {
714719
barrier();
715-
WRITE_ONCE(b, p);
720+
WRITE_ONCE(b, 1);
716721
do_something();
717722
} else {
718723
barrier();
719-
WRITE_ONCE(b, p);
724+
WRITE_ONCE(b, 1);
720725
do_something_else();
721726
}
722727

@@ -725,12 +730,12 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
725730

726731
q = READ_ONCE(a);
727732
barrier();
728-
WRITE_ONCE(b, p); /* BUG: No ordering vs. load from a!!! */
733+
WRITE_ONCE(b, 1); /* BUG: No ordering vs. load from a!!! */
729734
if (q) {
730-
/* WRITE_ONCE(b, p); -- moved up, BUG!!! */
735+
/* WRITE_ONCE(b, 1); -- moved up, BUG!!! */
731736
do_something();
732737
} else {
733-
/* WRITE_ONCE(b, p); -- moved up, BUG!!! */
738+
/* WRITE_ONCE(b, 1); -- moved up, BUG!!! */
734739
do_something_else();
735740
}
736741

@@ -742,10 +747,10 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
742747

743748
q = READ_ONCE(a);
744749
if (q) {
745-
smp_store_release(&b, p);
750+
smp_store_release(&b, 1);
746751
do_something();
747752
} else {
748-
smp_store_release(&b, p);
753+
smp_store_release(&b, 1);
749754
do_something_else();
750755
}
751756

@@ -754,10 +759,10 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
754759

755760
q = READ_ONCE(a);
756761
if (q) {
757-
WRITE_ONCE(b, p);
762+
WRITE_ONCE(b, 1);
758763
do_something();
759764
} else {
760-
WRITE_ONCE(b, r);
765+
WRITE_ONCE(b, 2);
761766
do_something_else();
762767
}
763768

@@ -770,18 +775,18 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
770775

771776
q = READ_ONCE(a);
772777
if (q % MAX) {
773-
WRITE_ONCE(b, p);
778+
WRITE_ONCE(b, 1);
774779
do_something();
775780
} else {
776-
WRITE_ONCE(b, r);
781+
WRITE_ONCE(b, 2);
777782
do_something_else();
778783
}
779784

780785
만약 MAX 가 1 로 정의된 상수라면, 컴파일러는 (q % MAX) 는 0이란 것을 알아채고,
781786
위의 코드를 아래와 같이 바꿔버릴 수 있습니다:
782787

783788
q = READ_ONCE(a);
784-
WRITE_ONCE(b, p);
789+
WRITE_ONCE(b, 1);
785790
do_something_else();
786791

787792
이렇게 되면, CPU 는 변수 'a' 로부터의 로드와 변수 'b' 로의 스토어 사이의 순서를
@@ -793,10 +798,10 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
793798
q = READ_ONCE(a);
794799
BUILD_BUG_ON(MAX <= 1); /* Order load from a with store to b. */
795800
if (q % MAX) {
796-
WRITE_ONCE(b, p);
801+
WRITE_ONCE(b, 1);
797802
do_something();
798803
} else {
799-
WRITE_ONCE(b, r);
804+
WRITE_ONCE(b, 2);
800805
do_something_else();
801806
}
802807

@@ -828,35 +833,33 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
828833

829834
q = READ_ONCE(a);
830835
if (q) {
831-
WRITE_ONCE(b, p);
836+
WRITE_ONCE(b, 1);
832837
} else {
833-
WRITE_ONCE(b, r);
838+
WRITE_ONCE(b, 2);
834839
}
835-
WRITE_ONCE(c, 1); /* BUG: No ordering against the read from "a". */
840+
WRITE_ONCE(c, 1); /* BUG: No ordering against the read from 'a'. */
836841

837-
컴파일러는 volatile 타입에 대한 액세스를 재배치 할 수 없고 이 조건 하의 "b"
842+
컴파일러는 volatile 타입에 대한 액세스를 재배치 할 수 없고 이 조건 하의 'b'
838843
로의 쓰기를 재배치 할 수 없기 때문에 여기에 순서 규칙이 존재한다고 주장하고
839844
싶을 겁니다. 불행히도 이 경우에, 컴파일러는 다음의 가상의 pseudo-assembly 언어
840-
코드처럼 "b" 로의 두개의 쓰기 오퍼레이션을 conditional-move 인스트럭션으로
845+
코드처럼 'b' 로의 두개의 쓰기 오퍼레이션을 conditional-move 인스트럭션으로
841846
번역할 수 있습니다:
842847

843848
ld r1,a
844-
ld r2,p
845-
ld r3,r
846849
cmp r1,$0
847-
cmov,ne r4,r2
848-
cmov,eq r4,r3
850+
cmov,ne r4,$1
851+
cmov,eq r4,$2
849852
st r4,b
850853
st $1,c
851854

852-
완화된 순서 규칙의 CPU 는 "a" 로부터의 로드와 "c" 로의 스토어 사이에 어떤
855+
완화된 순서 규칙의 CPU 는 'a' 로부터의 로드와 'c' 로의 스토어 사이에 어떤
853856
종류의 의존성도 갖지 않을 겁니다. 이 컨트롤 의존성은 두개의 cmov 인스트럭션과
854857
거기에 의존하는 스토어 에게만 적용될 겁니다. 짧게 말하자면, 컨트롤 의존성은
855858
주어진 if 문의 then 절과 else 절에게만 (그리고 이 두 절 내에서 호출되는
856859
함수들에게까지) 적용되지, 이 if 문을 뒤따르는 코드에는 적용되지 않습니다.
857860

858861
마지막으로, 컨트롤 의존성은 이행성 (transitivity) 을 제공하지 -않습니다-. 이건
859-
x 와 y 가 둘 다 0 이라는 초기값을 가졌다는 가정 하의 두개의 예제로
862+
'x' 와 'y' 가 둘 다 0 이라는 초기값을 가졌다는 가정 하의 두개의 예제로
860863
보이겠습니다:
861864

862865
CPU 0 CPU 1
@@ -924,6 +927,9 @@ http://www.cl.cam.ac.uk/users/pes20/ppc-supplemental/test6.pdf 와
924927
(*) 컨트롤 의존성은 이행성을 제공하지 -않습니다-. 이행성이 필요하다면,
925928
smp_mb() 를 사용하세요.
926929

930+
(*) 컴파일러는 컨트롤 의존성을 이해하고 있지 않습니다. 따라서 컴파일러가
931+
여러분의 코드를 망가뜨리지 않도록 하는건 여러분이 해야 하는 일입니다.
932+
927933

928934
SMP 배리어 짝맞추기
929935
--------------------

‎Documentation/virtual/uml/UserModeLinux-HOWTO.txt

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -2401,9 +2401,9 @@
24012401

24022402
This takes one argument, which is a single letter. It calls the
24032403
generic kernel's SysRq driver, which does whatever is called for by
2404-
that argument. See the SysRq documentation in Documentation/sysrq.txt
2405-
in your favorite kernel tree to see what letters are valid and what
2406-
they do.
2404+
that argument. See the SysRq documentation in
2405+
Documentation/admin-guide/sysrq.rst in your favorite kernel tree to
2406+
see what letters are valid and what they do.
24072407

24082408

24092409

0 commit comments

Comments
 (0)