Documentation/memory-barriers.txt
Source file repositories/reference/linux-study-clean/Documentation/memory-barriers.txt
File Facts
- System
- Linux kernel
- Corpus path
Documentation/memory-barriers.txt- Extension
.txt- Size
- 114239 bytes
- Lines
- 3017
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
struct rw_semaphorestruct rwsem_waiterfunction cpu0function cpu1function cpu2function cpu3function process_levelfunction interrupt_handlerfunction process_levelfunction interrupt_handlerfunction interrupt_handler
Annotated Snippet
struct rw_semaphore {
...
spinlock_t lock;
struct list_head waiters;
};
struct rwsem_waiter {
struct list_head list;
struct task_struct *task;
};
To wake up a particular waiter, the up_read() or up_write() functions have to:
(1) read the next pointer from this waiter's record to know as to where the
next waiter record is;
(2) read the pointer to the waiter's task structure;
(3) clear the task pointer to tell the waiter it has been given the semaphore;
(4) call wake_up_process() on the task; and
(5) release the reference held on the waiter's task struct.
In other words, it has to perform this sequence of events:
LOAD waiter->list.next;
LOAD waiter->task;
STORE waiter->task;
CALL wakeup
RELEASE task
and if any of these steps occur out of order, then the whole thing may
malfunction.
Once it has queued itself and dropped the semaphore lock, the waiter does not
get the lock again; it instead just waits for its task pointer to be cleared
before proceeding. Since the record is on the waiter's stack, this means that
if the task pointer is cleared _before_ the next pointer in the list is read,
another CPU might start processing the waiter and might clobber the waiter's
stack before the up*() function has a chance to read the next pointer.
Consider then what might happen to the above sequence of events:
CPU 1 CPU 2
=============================== ===============================
down_xxx()
Queue waiter
Sleep
up_yyy()
LOAD waiter->task;
STORE waiter->task;
Woken up by other event
<preempt>
Resume processing
down_xxx() returns
call foo()
foo() clobbers *waiter
</preempt>
LOAD waiter->list.next;
--- OOPS ---
This could be dealt with using the semaphore lock, but then the down_xxx()
function has to needlessly get the spinlock again after being woken up.
The way to deal with this is to insert a general SMP memory barrier:
LOAD waiter->list.next;
LOAD waiter->task;
smp_mb();
Annotation
- Detected declarations: `struct rw_semaphore`, `struct rwsem_waiter`, `function cpu0`, `function cpu1`, `function cpu2`, `function cpu3`, `function process_level`, `function interrupt_handler`, `function process_level`, `function interrupt_handler`.
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.