Menu
The implement of rcu_read_lock is disable preempt and barrier. And the softirq context will not be preempted. So is it necessary to invoke the rcu_read_lock in softirq context. Is the barrier important?
884
The bottom two can preempt each other, but above that is a strict hierarchy: each can only be preempted by the ones above it. For example, while a softirq is running on a CPU, no other softirq will preempt it, but a hardware interrupt can. However, any other CPUs in the system execute independently.
As a matter of fact, the term “softirq,” which appears in the kernel source code, often denotes both kinds of deferrable functions. Another widely used term is interrupt context : it specifies that the kernel is currently executing either an interrupt handler or a deferrable function.
From what I understand, rcu_read_lock() is used, where there are several read threads and one write thread, that read/writes the same data, and reading is performed under rcu_read_lock(), and the data are copied for each thread.
Grace period computation is a core part of the Read-Copy-Update (RCU) synchronization technique that determines the safe time to reclaim the deferred objects' memory.
Yes, it is necessary to use rcu_read_lock to access pointers that are under rcu protection, even in softirq context.
As you point out, some implementations (ex: TINY_RCU) of rcu_read_lock and softirqs make it so that there is no risk of corruption even if you don't delimit rcu read-side critical sections with rcu_read_lock. However, that is not a guarantee of the rcu api, only a "hack" because of the specific implementation. This hack could break with a different implementation of rcu (ex: PREEMPT_RCU).
If you wish to treat softirqs as explicit rcu read-side critical sections, you must use the RCU-sched api: Documentation/RCU/whatisRCU.txt
The following section of an article written by the main author of RCU directly addresses your question: Requirements for RCU part 1: the fundamentals - Disabling preemption does not block grace periods
I would add that code which does rcu_dereference outside of rcu_read_lock will trigger lockdep warnings if CONFIG_PROVE_RCU=y.
158
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
