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

[David Woodhouse]

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.

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