Merge tag 'lkmm.2025.05.25a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu

+5 -2

tools/memory-model/Documentation/README

··· 23 23 that you need, and just want to get started with LKMM litmus 24 24 tests: litmus-tests.txt 25 25 26 - o You would like to access lock-protected shared variables without 27 - having their corresponding locks held: locking.txt 26 + o You need to locklessly access shared variables that are otherwise 27 + protected by a lock: locking.txt 28 + 29 + This locking.txt file expands on the "Locking" section in 30 + recipes.txt, but is self-contained. 28 31 29 32 o You are familiar with Linux-kernel concurrency, and would 30 33 like a detailed intuitive understanding of LKMM, including

+1 -1

tools/memory-model/Documentation/explanation.txt

··· 1896 1896 1897 1897 3. The srcu_down_read() and srcu_up_read() primitives work 1898 1898 exactly like srcu_read_lock() and srcu_read_unlock(), except 1899 - that matching calls don't have to execute on the same CPU. 1899 + that matching calls don't have to execute within the same context. 1900 1900 (The names are meant to be suggestive of operations on 1901 1901 semaphores.) Since the matching is determined by the domain 1902 1902 pointer and index value, these primitives make it possible for

+5

tools/memory-model/Documentation/locking.txt

··· 1 + [!] Note: 2 + This file expands on the "Locking" section of recipes.txt, 3 + focusing on locklessly accessing shared variables that are 4 + otherwise protected by a lock. 5 + 1 6 Locking 2 7 ======= 3 8

+11 -11

tools/memory-model/Documentation/ordering.txt

··· 223 223 prohibits compiler code-motion optimizations that might move memory 224 224 references across the point in the code containing the barrier(), but 225 225 does not constrain hardware memory ordering. For example, this can be 226 - used to prevent to compiler from moving code across an infinite loop: 226 + used to prevent the compiler from moving code across an infinite loop: 227 227 228 228 WRITE_ONCE(x, 1); 229 229 while (dontstop) ··· 274 274 by the smp_store_release(), in this case "y", will normally be used in 275 275 an acquire operation in other parts of the concurrent algorithm. 276 276 277 - To see the performance advantages, suppose that the above example read 277 + To see the performance advantages, suppose that the above example reads 278 278 from "x" instead of writing to it. Then an smp_wmb() could not guarantee 279 279 ordering, and an smp_mb() would be needed instead: 280 280 ··· 394 394 to that subsequent memory access. 395 395 396 396 A call to rcu_dereference() for a given RCU-protected pointer is 397 - usually paired with a call to a call to rcu_assign_pointer() for that 398 - same pointer in much the same way that a call to smp_load_acquire() is 399 - paired with a call to smp_store_release(). Calls to rcu_dereference() 400 - and rcu_assign_pointer are often buried in other APIs, for example, 397 + usually paired with a call to rcu_assign_pointer() for that same pointer 398 + in much the same way that a call to smp_load_acquire() is paired with 399 + a call to smp_store_release(). Calls to rcu_dereference() and 400 + rcu_assign_pointer() are often buried in other APIs, for example, 401 401 the RCU list API members defined in include/linux/rculist.h. For more 402 402 information, please see the docbook headers in that file, the most 403 - recent LWN article on the RCU API (https://lwn.net/Articles/777036/), 403 + recent LWN article on the RCU API (https://lwn.net/Articles/988638/), 404 404 and of course the material in Documentation/RCU. 405 405 406 406 If the pointer value is manipulated between the rcu_dereference() 407 - that returned it and a later dereference(), please read 407 + that returned it and a later rcu_dereference(), please read 408 408 Documentation/RCU/rcu_dereference.rst. It can also be quite helpful to 409 409 review uses in the Linux kernel. 410 410 ··· 457 457 These operations come in three categories: 458 458 459 459 o Marked writes, such as WRITE_ONCE() and atomic_set(). These 460 - primitives required the compiler to emit the corresponding store 460 + primitives require the compiler to emit the corresponding store 461 461 instructions in the expected execution order, thus suppressing 462 462 a number of destructive optimizations. However, they provide no 463 463 hardware ordering guarantees, and in fact many CPUs will happily ··· 465 465 operations, unless these operations are to the same variable. 466 466 467 467 o Marked reads, such as READ_ONCE() and atomic_read(). These 468 - primitives required the compiler to emit the corresponding load 468 + primitives require the compiler to emit the corresponding load 469 469 instructions in the expected execution order, thus suppressing 470 470 a number of destructive optimizations. However, they provide no 471 471 hardware ordering guarantees, and in fact many CPUs will happily ··· 506 506 507 507 Unmarked C-language accesses are unordered, and are also subject to 508 508 any number of compiler optimizations, many of which can break your 509 - concurrent code. It is possible to used unmarked C-language accesses for 509 + concurrent code. It is possible to use unmarked C-language accesses for 510 510 shared variables that are subject to concurrent access, but great care 511 511 is required on an ongoing basis. The compiler-constraining barrier() 512 512 primitive can be helpful, as can the various ordering primitives discussed

+4

tools/memory-model/Documentation/recipes.txt

··· 61 61 Locking 62 62 ------- 63 63 64 + [!] Note: 65 + locking.txt expands on this section, providing more detail on 66 + locklessly accessing lock-protected shared variables. 67 + 64 68 Locking is well-known and straightforward, at least if you don't think 65 69 about it too hard. And the basic rule is indeed quite simple: Any CPU that 66 70 has acquired a given lock sees any changes previously seen or made by any

+1 -2

tools/memory-model/Documentation/references.txt

··· 46 46 47 47 o Imagination Technologies, LTD. 2015. "MIPS(R) Architecture 48 48 For Programmers, Volume II-A: The MIPS64(R) Instruction, 49 - Set Reference Manual". Imagination Technologies, 50 - LTD. https://imgtec.com/?do-download=4302. 49 + Set Reference Manual". Imagination Technologies, LTD. 51 50 52 51 o Shaked Flur, Kathryn E. Gray, Christopher Pulte, Susmit 53 52 Sarkar, Ali Sezgin, Luc Maranget, Will Deacon, and Peter

+2 -2

tools/memory-model/Documentation/simple.txt

··· 134 134 Lockless programming is considered by many to be more difficult than 135 135 lock-based programming, but there are a few lockless design patterns that 136 136 have been built out into an API. One of these APIs is sequence locking. 137 - Although this APIs can be used in extremely complex ways, there are simple 137 + Although this API can be used in extremely complex ways, there are simple 138 138 and effective ways of using it that avoid the need to pay attention to 139 139 memory ordering. 140 140 ··· 205 205 operations from the previous section only when there are no racing 206 206 accesses. Otherwise, use only fully ordered operations when accessing 207 207 or modifying the variable. This approach guarantees that code prior 208 - to a given access to that variable will be seen by all CPUs has having 208 + to a given access to that variable will be seen by all CPUs as having 209 209 happened before any code following any later access to that same variable. 210 210 211 211 Please note that per-CPU functions are not atomic operations and

Configure Feed

Configure Feed