On Tue, Aug 11, 2020 at 09:02:40AM -0700, Paul E. McKenney wrote: > On Tue, Aug 11, 2020 at 05:43:16PM +0200, Thomas Gleixner wrote: > > "Paul E. McKenney" <paulmck@xxxxxxxxxx> writes: > > > On Tue, Aug 11, 2020 at 04:44:21PM +0200, Thomas Gleixner wrote: > > >> Now RCU creates a new thing which enforces to make page allocation in > > >> atomic context possible on RT. What for? > > >> > > >> What's the actual use case in truly atomic context for this new thing on > > >> an RT kernel? > > > > > > It is not just RT kernels. CONFIG_PROVE_RAW_LOCK_NESTING=y propagates > > > this constraint to all configurations, and a patch in your new favorite > > > subsystem really did trigger this lockdep check in a non-RT kernel. > > > > > >> The actual RCU code disabling interrupts is an implementation detail > > >> which can easily be mitigated with a local lock. > > > > > > In this case, we are in raw-spinlock context on entry to kfree_rcu(). > > > > Where? > > Some BPF code that needs to process and free a list. As noted above, > this is a patch rather than something that is already in mainline. > Not surprising, though, given call_rcu() invocations in similar contexts. > > Yes, we can perhaps rework all current and future callers to avoid > invoking both call_rcu() and kfree_rcu() from raw atomic context, but > the required change to permit this is quite a bit simpler. I should hasten to add that from what I can see right now, the required change allows telling the memory allocator bail out instead of acquiring a non-raw spinlock. I am absolutely not advocating converting the allocator's spinlocks to raw spinlocks. Thanx, Paul
