On 30/09/21 00:10, Frederic Weisbecker wrote: > The current condition to limit the number of callbacks executed in a > row checks the offloaded state of the rdp. Not only is it volatile > but it is also misleading: the rcu_core() may well be executing > callbacks concurrently with NOCB kthreads, and the offloaded state > would then be verified on both cases. As a result the limit would > spuriously not apply anymore on softirq while in the middle of > (de-)offloading process. > > Another issue with the condition is that rcu_is_callbacks_kthread() > doesn't check if we are actually running callbacks from rcuc itself or > from a softirq interrupting rcuc. > Doesn't rcutree.use_softirq imply rcuc is never woken, in which case RCU_SOFTIRQ can't interrupt rcuc (e.g. while run atop an IRQ exit)? I suppose during the (de)offload sequence we could have RCU_SOFTIRQ running atop the NOCB CB kthread, but that's not something rcu_is_callbacks_kthread() detects. Also, why is rcu_is_callbacks_kthread() hardcoded to false for !CONFIG_RCU_BOOST? Isn't it relevant for do_rcu_batch() ratelimiting regardless (at least before your patches)?
