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

[Sebastian Andrzej Siewior]

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…

Sebastian