On Thu, Mar 19, 2026 at 03:05:40AM -0700, Paul E. McKenney wrote:
> On Thu, Mar 19, 2026 at 09:55:48AM +0100, Sebastian Andrzej Siewior wrote:
> > On 2026-03-18 11:48:56 [-0700], Paul E. McKenney wrote:
> > > We would need a lockless enqueue, which we have in llist.h.
> >
> > Only if CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG. Otherwise you must not
> > provide call_rcu_nmi().
>
> I *think* that BPF is provided only in such architectures, so agreed.
Plus srcu_read_lock_fast() uses atomic_long_inc(), which is supposed to
be NMI-safe anyway, correct?
Thanx, Paul
> > > The irq-work to actually do the call_rcu() or similar.
> >
> > reasonable.
> >
> > > There would also need to be rcu_barrier() changes, for example, to
> > > drain all the llists.
> > >
> > > > I mean I am curious here who needs it any why ;)
> > >
> > > You got it right above, BPF. ;-)
> > >
> > > They currently check in_nmi() and to the irq-work step themselves.
> >
> > Then it would make sense since you do actually have users.
>
> For more fun, they would like to attach BPF programs to call_rcu() and
> call_srcu() internals, which would require a per-task recursion check.
> Or perhaps some other trick.
>
> Thanx, Paul
