6

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?

linuxer
  • 326
  • 4
  • 14

3 Answers3

1

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.

gobenji
  • 299
  • 2
  • 5
0

The rcu_read_lock is to protect some kernel resource being modify simulanteously that causes race condition error.

What a resource must to prevent is: being simultaneously use and modified by two software task/ context.

In Linux, the simultaneously modification may happens in either:

  1. context swithing from task to task,
  2. context swithing from task to IRQ context
  3. concurrent accessing from task in different VCPU cores

Event in a single core CPU environment, the 1) and 2) may still happens. On task modifying a critical resource, a software IRQ raise, enter the software IRQ context, run IRQ handler and modifying the same resource simultaneously.

Houcheng
  • 2,674
  • 25
  • 32
  • But the softirq is not preempted by other softirq and normal task. – linuxer Feb 14 '14 at 02:53
  • the resource is needed to be protected by a lock if it may be concurrently accessed. For example, a thread is modifying a resource and resource is in a quasi state, the software irq entering and modify this resource that cause race conditions. – Houcheng Feb 17 '14 at 02:44
  • Besides, there may be several VCPU concurrently runs software irq and tasks at the same moment. If that resource is not only accessed by a software-irq, should protect it from simultaneously access. – Houcheng Feb 17 '14 at 02:45
  • But my question is that the rcu_read_lock is necessary in softirq context? Because the rcu_read_lock only implement the preempt_disable. – linuxer Feb 18 '14 at 02:51
  • Oh, i missed this part. you have to use the MACRO: rcu_read_lock_bh if resource is read from bottom half. this macro disable preempt of thread and bottom halves. – Houcheng Mar 04 '14 at 10:15
  • The resource is read from softirq, not bottom half(it will include softirq, tasklet, workqueue). The bh is disabled in softirq context, so i think the rcu_read_lock_bh is useless in this case. – linuxer Mar 05 '14 at 13:01
0

It is a good idea to invoke rcu_read_lock in a softirq context for document purposes, so you and other developers know that RCU protected data is used here.

Nathaniel Ford
  • 20,545
  • 20
  • 91
  • 102
Yi Jin
  • 1