Re: [PATCH] mm/mmu_notifier: Remove non_block_start/end() from notifier invocation

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2597 bytes --]

(Correcting Sean's email address)

On Tue, 2026-08-11 at 11:27 -0300, Jason Gunthorpe wrote:
> On Tue, Aug 11, 2026 at 03:21:35PM +0100, David Woodhouse wrote:
> > > >  - On PREEMPT_RT, spinning locks become sleeping locks, and perfectly
> > > >    legitimate spinlock/rwlock usage in notifier implementations (e.g.
> > > >    KVM's mn_invalidate_lock and gfn_to_pfn_cache locks) triggers the
> > > >    splat despite having no allocator dependency whatsoever. This is
> > > >    reproducible today on a PREEMPT_RT kernel: KVM takes
> > > >    kvm->mn_invalidate_lock in kvm_mmu_notifier_invalidate_range_start(),
> > > >    and if the OOM reaper reaps a KVM process the result is a "BUG:
> > > >    sleeping function called from invalid context" from
> > > >    rt_spin_lock().
> > > 
> > > I don't know anything about PREEEMPT_RT, but this seems like an issue
> > > with RT if a traditionally atomic safe functions are now triggering
> > > might sleep failures?
> > 
> > I can sympathise with that point of view. In fact I've spent the last
> > couple of years mostly ignoring this "problem" and just blaming RT for
> > doing exactly that, but I don't think we can really get away with it
> > any more.
> > 
> > cf. https://lore.kernel.org/all/787aa26cf62dfd361eea8ed19f384fc517892501.camel@infradead.org/
> 
> If might_sleep doesn't work sanely at all in preempt_rt then just
> globally turn it off?

Turn might_sleep off? Or PREEMPT_RT? :)

The RT maintainers are on this thread if you want to pick either of
those fights... that was not the course of action I chose to take.

> > > >  - A notifier implementation may legitimately need to wait for an RCU
> > > >    grace period before allowing the caller to proceed with unmapping
> > > 
> > > That's not allowed. We really want to forbid that, it is not an
> > > acceptable way to implement a driver using these APIs due to
> > > performance.
> > 
> > Speak for yourself. For the KVM gfn-to-pfn-cache the performance scales
> > *much* better with RCU than with explicit locking:
> > https://lore.kernel.org/all/8f41cb82b7c99d5a3d1dda016e4841326b4d8a52.camel@infradead.org/
> 
> At the cost of completely destroying the mm shootdown performance with
> 1s RCU grace period waits every mm operation. No thanks.

I feel like we're not talking about the same things here.

The KVM patch which this enables does *not* behave as you have
described. Have you looked at it?

Nobody's suggesting that we force any *other* MMU notifiers to do
anything that they don't do today.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6179 bytes --]