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

On 2026-08-20 15:26:35 [+0100], David Woodhouse wrote:
> 
> So if you fix the might_sleep() and Paul comes through with the atomic
> SRCU thing, I no longer care *much*, but still think the whole thing
> deserves to die.

Okay. Let me look into it then. But "the whole thing deserves to die" is
limited to the kvm usage, not in the kernel?

> Going back to SRCU atomic (citing your mail in reverse order):
> > In
> >    https://lore.kernel.org/all/[email protected]
> > there was a suggestion for "srcu: Add an ATOMIC reader flavor and a spinning
> > synchronize_srcu_atomic()". This one had preempt_disable() in
> > srcu_read_lock_atomic(). This is bad as not only forbids to acquire any
> > sleeping locks (such as spinlock_t) but it also does not allow any
> > scheduling of any kind within this section.
> 
> That was kind of the point :) 
> 
> My srcu_read_lock_atomic/synchronize_srcu_atomic() were born of the
> "need" to avoid scheduling in OOM (RT or no), but actually I think they
> survive even when that requirement goes away. Even with my
> try_synchronize_srcu() optimisation, we saw higher tail latencies when
> deferring to the workqueue, and Sean was very much in favour of
> eliminating those.
> 
> So I think we do want synchronize_srcu_atomic() if Paul can find a way
> to give us that.
> 
> To your point about preempt_disable() in srcu_read_lock_atomic() on the
> read side... I don't know if we *need* it to be like that. When I threw
> it together, I was thinking of it as a raw_spinlock, in the "must not
> sleep" mindset.
> 
> In fact, as long as the splats are dealt with, it would probably be OK
> for it to be equivalent to a non-raw spinlock: disable preemption on
> non-RT, but not on RT. I think that's perfectly OK for us from the KVM
> point of view. But does heavily depend on how Paul wants to implement
> it, of course.

okay.

Sebastian