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

[Sean Christopherson <seanjc@google.com>]

On Thu, Aug 13, 2026, David Woodhouse wrote:
> On Wed, 2026-08-12 at 15:38 +0100, David Woodhouse wrote:
> > On Wed, 2026-08-12 at 11:26 -0300, Jason Gunthorpe wrote:
> > > On Wed, Aug 12, 2026 at 03:05:43PM +0100, David Woodhouse wrote:
> > > > the non_block_{start,end} guards around the MMU notifiers, which are
> > > > basically never being called anyway and don't actually seem to protect
> > > > against any real bugs.
> > > 
> > > If you think this blocked stuff is dead code then lets remove it, but
> > > I'm pretty sure it is called and I remember seeing bug reports about
> > > it being triggered in the wild. Vetter certainly added it because
> > > their tests were actually triggering and they had bugs in their DRM
> > > stack directly connected to this.
> > > 
> > > It might not trigger for your hypervisor case but we aren't here just
> > > to make only kvm work now are we?
> > 
> > I'm sure there can be real-world use cases where it can trigger, but
> > when I was *trying* to exercise the code path, to validate my belief
> > (from source inspection) that even the plain spinlock would trigger the
> > splat, I ended up having to hack the kernel to do so:
> > 
> > https://lore.kernel.org/all/787aa26cf62dfd361eea8ed19f384fc517892501.camel@infradead.org/
> > 
> > Perhaps in the past it was easier to trigger 'naturally'?
> 
> I did a bit more digging. On the one hand, I was wrong to claim that it
> never triggers — there *are* a handful of reports; of my searches this
> was probably the most fruitful:
> https://lore.kernel.org/all/?q=%22non_block%3A+1%22
> 
> On the other hand, they are basically *all* false positives from the
> point of view of what the check was actually trying to do. And in KVM.

FWIW, all of the KVM false positives are due to PREEMPT_RT turning mmu_lock into
a sleepable lock on x86.  So killing off the restriction for PREEMPT_RT would
"fix" the KVM issues.

> It's causing more issues than it fixes. Including some bizarre MM
> gymnastics: https://lore.kernel.org/all/amMZFqs1smKmMuj5@lucifer/
> 
> At this point I don't think I even *care* whether we manage to do the
> atomic SRCU thing; I think this check should die *anyway*.