Commit 954e6e03 authored by Linus Torvalds's avatar Linus Torvalds

Merge tag '4.13-fixes' of git://git.lwn.net/linux

Pull documentation fixes from Jonathan Corbet:
 "A set of fixes for various warnings, including the one caused by the
  removal of kernel/rcu/srcu.c. Also correct a stray pointer in
  memory-barriers.txt"

* tag '4.13-fixes' of git://git.lwn.net/linux:
  kokr/memory-barriers.txt: Fix obsolete link to atomic_ops.txt
  memory-barriers.txt: Fix broken link to atomic_ops.txt
  docs: Turn off section numbering for the input docs
  docs: Include uaccess docs from the right file
  docs: Do not include from kernel/rcu/srcu.c
parents 80fc6238 51e988f4
......@@ -114,7 +114,7 @@ The Slab Cache
User Space Memory Access
------------------------
.. kernel-doc:: arch/x86/include/asm/uaccess_32.h
.. kernel-doc:: arch/x86/include/asm/uaccess.h
:internal:
.. kernel-doc:: arch/x86/lib/usercopy_32.c
......
......@@ -106,9 +106,6 @@ Kernel utility functions
.. kernel-doc:: kernel/sys.c
:export:
.. kernel-doc:: kernel/rcu/srcu.c
:export:
.. kernel-doc:: kernel/rcu/tree.c
:export:
......
......@@ -6,7 +6,6 @@ Contents:
.. toctree::
:maxdepth: 2
:numbered:
input_uapi
input_kapi
......
......@@ -1876,8 +1876,8 @@ There are some more advanced barrier functions:
This makes sure that the death mark on the object is perceived to be set
*before* the reference counter is decremented.
See Documentation/atomic_ops.txt for more information. See the "Atomic
operations" subsection for information on where to use these.
See Documentation/core-api/atomic_ops.rst for more information. See the
"Atomic operations" subsection for information on where to use these.
(*) lockless_dereference();
......@@ -2584,7 +2584,7 @@ situations because on some CPUs the atomic instructions used imply full memory
barriers, and so barrier instructions are superfluous in conjunction with them,
and in such cases the special barrier primitives will be no-ops.
See Documentation/atomic_ops.txt for more information.
See Documentation/core-api/atomic_ops.rst for more information.
ACCESSING DEVICES
......
......@@ -523,11 +523,11 @@ CPU 에게 기대할 수 있는 최소한의 보장사항 몇가지가 있습니
즉, ACQUIRE 는 최소한의 "취득" 동작처럼, 그리고 RELEASE 는 최소한의 "공개"
처럼 동작한다는 의미입니다.
atomic_ops.txt 에서 설명되는 어토믹 오퍼레이션들 중에는 완전히 순서잡힌 것들과
(배리어를 사용하지 않는) 완화된 순서의 것들 외에 ACQUIRE 와 RELEASE 부류의
것들도 존재합니다. 로드와 스토어를 모두 수행하는 조합된 어토믹 오퍼레이션에서,
ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE 는 해당
오퍼레이션의 스토어 부분에만 적용됩니다.
core-api/atomic_ops.rst 에서 설명되는 어토믹 오퍼레이션들 중에는 완전히
순서잡힌 것들과 (배리어를 사용하지 않는) 완화된 순서의 것들 외에 ACQUIRE 와
RELEASE 부류의 것들도 존재합니다. 로드와 스토어를 모두 수행하는 조합된 어토믹
오퍼레이션에서, ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE 는
해당 오퍼레이션의 스토어 부분에만 적용됩니다.
메모리 배리어들은 두 CPU 간, 또는 CPU 와 디바이스 간에 상호작용의 가능성이 있을
때에만 필요합니다. 만약 어떤 코드에 그런 상호작용이 없을 것이 보장된다면, 해당
......@@ -1848,7 +1848,7 @@ Mandatory 배리어들은 SMP 시스템에서도 UP 시스템에서도 SMP 효
이 코드는 객체의 업데이트된 death 마크가 레퍼런스 카운터 감소 동작
*전에* 보일 것을 보장합니다.
더 많은 정보를 위해선 Documentation/atomic_ops.txt 문서를 참고하세요.
더 많은 정보를 위해선 Documentation/core-api/atomic_ops.rst 문서를 참고하세요.
어디서 이것들을 사용해야 할지 궁금하다면 "어토믹 오퍼레이션" 서브섹션을
참고하세요.
......@@ -2550,7 +2550,7 @@ CPU 에서는 사용되는 어토믹 인스트럭션 자체에 메모리 배리
있는데, 그런 경우에 이 특수 메모리 배리어 도구들은 no-op 이 되어 실질적으로
아무일도 하지 않습니다.
더 많은 내용을 위해선 Documentation/atomic_ops.txt 를 참고하세요.
더 많은 내용을 위해선 Documentation/core-api/atomic_ops.rst 를 참고하세요.
디바이스 액세스
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment