Re: [RFC PATCH 00/12] RCU pseudo-transactions

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2026-11-09 20:34, Paul E. McKenney wrote:
[...]
>> Would you prefer to add these two variants on the SRCU side, or should
>> I prototype them with the next version of this series?
>
> Your choice!

I'll do it. Adapting atomic SRCU to these needs is much more
maintainable than keeping my own copy of nearly the same mechanism.

> If you would like to do it, the trick is to make srcu_read_lock_atomic()
> and srcu_read_unlock_atomic() invoke __srcu_read_lock_fast() and
> __srcu_read_unlock_fast(), respectively, instead of __srcu_read_lock()
> and __srcu_read_unlock(), again respectively.

I'll start by making every atomic reader NMI-safe this way, as you
suggest. If David objects, we can still change it based on his
feedback.

> Then there would need to be an srcu_read_lock_atomic_irqsafe() and
> srcu_read_unlock_irqrestore(), which would (as you say), replace
> preempt_disable() with local_irq_save() and preempt_enable()
> with local_irq_restore().  There would be a flags argument that
> as far as I know requires srcu_read_lock_atomic_irqsafe() and
> srcu_read_unlock_irqrestore() be macros.  It would be good to share code
> with srcu_read_lock_atomic() and srcu_read_unlock_atomic().

Agreed. I plan to name them srcu_read_lock_atomic_irqsave() and
srcu_read_unlock_atomic_irqrestore(), as macros sharing code with the
current pair.

> And kernel/rcu/rcutorture.c would need a bit of tweaking to test
> this new interface, which should be discoverable by looking for
> the code that tests srcu_read_{,un}lock_atomic().  Maybe just make
> srcu_torture_read_lock() randomly decide between srcu_read_lock_atomic()
> and srcu_read_lock_atomic_irqsave(), and have srcu_torture_read_unlock()
> follow that decision.
>
> One potentially tricky part here is that rcutorture is not set up to
> pass a flags variable from a read-lock to the corresponding read-unlock.

I'll look at the rcutorture side as part of it.

A later version of rcu_txn will then use these readers, instead of its
own per-CPU counters.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com