Re: [PATCH v2 01/20] locking/rt: Use raw_spin_lock_irqsave() in __rwbase_read_unlock()

On Mon, 2026-06-01 at 16:47 +0200, Sebastian Andrzej Siewior wrote:
> On 2026-06-01 14:53:14 [+0100], David Woodhouse wrote:
> > On Mon, 2026-06-01 at 15:40 +0200, Sebastian Andrzej Siewior wrote:
> > > 
> > > Okay. This complains about non_block:
> > > 
> > > …
> > > > [  429.927260] KVM: non-blockable invalidate_range_start, non_block_count=1
> > > 
> > > and commit 312364f3534cc ("kernel.h: Add non_block_start/end()") says
> > > 
> > > >     Peter also asked whether we want to catch spinlocks on top, but Michal
> > > >     said those are less of a problem because spinlocks can't have an indirect
> > > >     dependency upon the page allocator and hence close the loop with the oom
> > > >     reaper.
> > > 
> > > so a lock which becomes sleep-able on RT vs !RT shouldn't be a problem,
> > > right? We also don't complain about about scheduling within a
> > > rcu_read_lock() section if it is part of spin_lock().
> > 
> > Right. This is just a false positive in the debugging check, AFAICT.
> > 
> > It's actually *fine* to take a spinlock or rwlock in the OOM reaper
> > path, *even* if RT makes them in sleepable locks. And I think even the
> > KVM_REQUEST_WAIT IPI is fine.
> > 
> > But to fix the false positive warning, *either*:
> > 
> >  • non_block_start() shouldn't complain about "sleepable only in RT" locks,
> > 
> > OR 
> > 
> >  • The OOM reaper path shouldn't use non_block_start() under RT.
> 
> Looking at the list of users it was probably introduced for the mm
> folks. Let me add this to my list of things to look at…

I'm leaning toward the second of the two options above: the OOM reaper
path shouldn't use non_block_start() under RT. Effectively reverting
commit ba170f76b69d1.

Mostly because I want to have an RCU grace period in there, and *that*
would splat too, for no good reason that I can see.