Re: [RFC v2] rcu/tree: Try to invoke_rcu_core() if in_irq() during unlock

[Joel Fernandes <joel@joelfernandes.org>]

On Wed, Aug 21, 2019 at 08:39:57AM -0700, Paul E. McKenney wrote:
> On Wed, Aug 21, 2019 at 10:56:17AM -0400, Joel Fernandes wrote:
[snip]
> > I think one reason could be, in_irq() is false when the timer callback
> > executes, since the timer callback is executing after a grace-period. The
> > stack is as follows:
> > 
> > Any reason why we cannot both test for call_rcu() and execute the RCU
> > callback from the timer hardirq handler?
> > 
> > In fact, I guess on use_nosoftirq systems, the callback will not even run
> > in softirq context.
> > 
> > [   20.553361]  => rcu_torture_timer_cb
> > [   20.553361]  => rcu_do_batch
> > [   20.553361]  => rcu_core
> > [   20.553361]  => __do_softirq
> > [   20.553361]  => do_softirq_own_stack
> > [   20.553361]  => do_softirq.part.16
> > [   20.553361]  => __local_bh_enable_ip
> > [   20.553361]  => rcutorture_one_extend
> > [   20.553361]  => rcu_torture_one_read
> > [   20.553361]  => rcu_torture_reader
> > [   20.553361]  => kthread
> > [   20.553361]  => ret_from_fork
> 
> Well, it is rcu_read_lock() and rcu_read_unlock() that matters

True!

> for this case rather than the callback.  But yes, given in_irq(),
> rcu_read_lock() and rcu_read_unlock() would need to have executed
> from a hardware interrupt handler.  And would need to get one of the
> ->rcu_read_lock_special bits set somehow.
> 
> But you can use smp_call_function() to invoke a function that runs in
> hardware interrupt handler context, and you can do this within either
> rcuperf or rcutorture.
> 
> And yes, this line of reasoning did inform at least some of my skepticism
> surrounding your initial patch, in case you were wondering about some
> of my earlier questions.  ;-)

Sounds great, I will try to modify the tests to trigger this case and also
look into your other questions. Thanks!!

 - Joel