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
