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

[David Woodhouse]

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…

Thanks. For the purpose of KVM we shall ignore the issue and assume
it's going away. It is safe to take both spinlocks *and* rwlocks in the
"!may_block" invalidation path.

And probably OK to IPI a vCPU to GTFO too, but we'll discuss that under
separate cover: 
https://lore.kernel.org/all/7428996952122d5943715c8682c6ad1c353566f9.camel@xxxxxxxxxxxxx

Attachment: smime.p7s
Description: S/MIME cryptographic signature