On Wed, Apr 22, 2020 at 09:19:55AM -0700, Paul E. McKenney wrote: > On Wed, Apr 22, 2020 at 05:46:25PM +0200, Sebastian Andrzej Siewior wrote: > > On 2020-04-22 06:33:46 [-0700], Paul E. McKenney wrote: > > > On Wed, Apr 22, 2020 at 01:13:24PM +0200, Sebastian Andrzej Siewior wrote: > > > > On 2020-04-21 11:09:14 [-0700], Paul E. McKenney wrote: > > > > > > Yes but why do we do this raw_spinlock_t here? It is not yet needed on > > > > > > v5.6-RT as I *did* check. It also complicates the code for !RT but > > > > > > nobody responded to that part but… > > > > > > > > > > I did respond by pointing out that the essentially similar call_rcu() > > > > > function ends up being invoked pretty much everywhere, including early > > > > > boot before rcu_init() has been invoked. It is therefore only reasonable > > > > > to assume that there will be a need for kfree_rcu() to tolerate a similar > > > > > range of calling contexts. > > > > > > > > Early in the boot we have IRQs disabled but also one CPU and no > > > > scheduling. That means that not a single lock is contained. > > > > > > You are saying that call_rcu() is never invoked while holding a raw > > > spinlock? > > > > I didn't say that. I said if you use spin_lock() with interrupts > > disabled *but* early in the boot process (without the scheduler active) > > then it is okay. > > This was a response to your "including early boot before …". > > But since you ask: On top of my head I know that > > task_struct is released via RCU by the scheduler in a preempt-disabled > > section. We have a similar workaround for the mm struct. So yes, we have > > at the very least those two. In case your question is "Why can call_srcu() be restricted but not kfree_rcu()", the answer is that call_srcu() has all of five call sites outside of rcutorture and friends. So this restriction is much more likely to stick for call_srcu() than for kfree_rcu(). Thanx, Paul > > > Fair enough, and thank you for checking! > > > > > > The other work-queuing operations are also OK as they are, then? > > > > yes. > > Very good, and again, thank you! > > Thanx, Paul