Re: [PATCH v2 3/6] srcu: Make call_srcu() safe to call from any context

On Mon, Aug 3, 2026 at 3:49=E2=80=AFPM <[email protected]> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issu=
e(s) to consider:
>
> Pre-existing issues:
> - [High] Tiny SRCU's call_srcu() remains unsafe to call from NMI context,=
 leaving it vulnerable to list corruption.
> --
>
> --- Patch [3]: [PATCH v2 3/6] srcu: Make call_srcu() safe to call from an=
y context ---
> commit e3be0303432c7c7afdd4ed014dae0987e25bf7d3
> Author: Puranjay Mohan <[email protected]>
>
> srcu: Make call_srcu() safe to call from any context
>
> This commit updates Tree SRCU to make call_srcu() safe to call from any
> context, including NMIs. It defers callbacks via a per-CPU irq_work when
> interrupts are already disabled to prevent list corruption and deadlocks.
>
> > srcu: Make call_srcu() safe to call from any context
> >
> > call_srcu() has the same constraint as call_rcu(): its callback list an=
d
> > locks are only touched with interrupts disabled.  srcu_gp_start_if_need=
ed()
> > enqueues under raw_spin_lock_irqsave() and may walk the srcu_node tree,=
 as
> > do callback invocation and grace-period work.  A call_srcu() with
> > interrupts disabled can race a list operation in flight on this CPU and
> > corrupt the list or deadlock.  call_rcu_tasks_trace() is call_srcu() un=
der
> > the hood, so a sleepable BPF program freeing an object can reach this.
>
> [Severity: High]
> This isn't a bug introduced by this patch, but does Tiny SRCU also need a
> similar fix to safely handle NMI contexts?
>
> In kernel/rcu/srcutiny.c, call_srcu() relies solely on local_irq_save(),
> which does not mask NMIs:
>
>         local_irq_save(flags);
>         *ssp->srcu_cb_tail =3D rhp;
>         ssp->srcu_cb_tail =3D &rhp->next;
>         local_irq_restore(flags);
>
> If an NMI interrupts call_srcu() exactly between assigning the tail and
> updating the tail pointer, and the NMI handler invokes call_srcu()
> (e.g., via call_rcu_tasks_trace()) on the same srcu_struct, could this
> overwrite the tail pointer and permanently detach the list?

See next patch it fixed tiny srcu.