On Mon, Feb 24, 2020 at 10:55 PM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: [...] > > > As for "task_struct's rcu_read_lock_nesting". Will it be enough just > > > have a look at preempt_count of current process? If we have for example > > > nested rcu_read_locks: > > > > > > <snip> > > > rcu_read_lock() > > > rcu_read_lock() > > > rcu_read_lock() > > > <snip> > > > > > > the counter would be 3. > > > > No, because preempt_count is not incremented during rcu_read_lock(). RCU > > reader sections can be preempted, they just cannot goto sleep in a reader > > section (unless the kernel is RT). > > You are both right. > > Vlad is correct for CONFIG_PREEMPT=n and CONFIG_DEBUG_ATOMIC_SLEEP=y > and Joel is correct otherwise, give or take the possibility of other > late-breaking corner cases. ;-) Oh yes, but even for PREEMPT=n, rcu_read_lock() is just a NOOP for that configuration and doesn't really mess around with preempt_count if I recall :-D. (doesn't need to mess with preempt_count because being in kernel mode is non-preemptible for PREEMPT=n anyway). thanks, - Joel
