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

[Sebastian Andrzej Siewior]

On 2026-08-26 14:04:32 [-0700], Paul E. McKenney wrote:
> > >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.
> 
> OK, the traditional approach is that raw_synchronize_srcu_atomic() and
> friends with the raw_ prefix are always atomic, and without the raw_
> prefix it is atomic for !PREEMPT_RT and non-atomic otherwise.  You would
> use the non-_raw primitives.
> 
> Easy enough to do.  But does it do the job, both from a PREEMPT_RT
> perspective and a notifier perspective?

It does not lead to any lock violations so that is a plus.

> And notifiers (though a different type of them) were the first use case
> for SRCU.  ;-)
> 
> 							Thanx, Paul

Sebastian