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

[David Woodhouse]

On 26 August 2026 20:59:31 BST, "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote:
>On Wed, Aug 26, 2026 at 07:01:24PM +0100, David Woodhouse wrote:
>> On 26 August 2026 17:28:27 BST, "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote:
>> >On Wed, Aug 26, 2026 at 08:05:06AM -0700, Paul E. McKenney wrote:
>> >> On Wed, Aug 26, 2026 at 08:38:27AM +0100, David Woodhouse wrote:
>> >> > On Wed, 2026-08-26 at 09:32 +0200, Sebastian Andrzej Siewior wrote:
>> >> > > On 2026-08-25 13:51:14 [-0700], Paul E. McKenney wrote:
>> >> > > > Very good, preemption disabling it is!  It is quite possible that the
>> >> > > > PREEMPT_RT guys will need something else, but one thing at a time.
>> >> > > 
>> >> > > This reminds me of classic RCU ;) It might work in this use case but I
>> >> > > am afraid that other users might come along where it actually hurts.
>> >> > > With PREEMPT LAZY the preemption within the read-section should
>> >> > > hopefully be the exception.
>> >> > 
>> >> > Given the way that PREEMPT_RT treats other locks like spinlocks and
>> >> > rwlocks — turning them into sleeping locks — I suspect it makes most
>> >> > sense, and is consistent, to also turn rcu_read_lock_atomic() and
>> >> > synchronize_rcu_atomic() into plain rcu_read_lock() and
>> >> > try_synchronize_srcu()+synchronize_scru_expedited().
>> >> 
>> >> That makes a lot of sense to me.
>> >
>> >Another option is to instead fall back to non-atomic SRCU.
>> 
>> That's exactly what I thought I was suggesting; I think I left an 's' out though :)
>
>Heh!!!
>
>About 20 years ago, I was shocked to learn of a valid use case involving
>sleeping RCU readers, which resulted in SRCU.  And now it is time
>to be shocked at non-sleeping sleeping RCU readers, and especially a
>non-sleeping grace-period wait.  ;-)
>
>Anyway, easy enough:
>
>#ifdef CONFIG_PREEMPT_RT
>DEFINE_SRCU(whatever);
>#define my_srcu_read_lock() srcu_read_lock(&whatever);
>#define my_srcu_read_unlock(idx) srcu_read_unlock(&whatever, (idx));
>#define my_synchronize_srcu() synchronize_srcu(&whatever);
>#else
>DEFINE_SRCU_ATOMIC(whatever);
>#define my_srcu_read_lock() srcu_read_lock_atomic(&whatever);
>#define my_srcu_read_unlock(idx) srcu_read_unlock_atomic(&whatever, (idx));
>#define my_synchronize_srcu() synchronize_srcu_atomic(&whatever);
>#endif

We could do that for the KVM GPC locking, but more consistent would be to change *all* users of the 'atomic' lock under PREEMPT_RT to silently get the sleeping version instead, like PREEMPT_RT does with spinlocks and rwlocks.

So it's srcu_read_lock_atomic() itself (et al) which would get that if/else treatment.