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. > Fair enough, and thank you for checking! > > The other work-queuing operations are also OK as they are, then? yes. Sebastian
