On Tue, Feb 25, 2020 at 11:42 AM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: > > On Tue, Feb 25, 2020 at 09:17:11AM -0500, Joel Fernandes wrote: > > 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). > > For PREEMPT=n, rcu_read_lock() is preempt_disable(), see the code > in include/linux/rcupdate.h. ;-) Paul.... ;-) ;-) thanks, - Joel
