Re: [PATCH v2] rcu: Use an intermediate irq_work to start process_srcu()

Quoting Boqun Feng (2026-03-20 23:29:16)
> Since commit c27cea4416a3 ("rcu: Re-implement RCU Tasks Trace in terms
> of SRCU-fast") we switched to SRCU in BPF. However as BPF instrument can
> happen basically everywhere (including where a scheduler lock is held),
> call_srcu() now needs to avoid acquiring scheduler lock because
> otherwise it could cause deadlock [1]. Fix this by following what the
> previous RCU Tasks Trace did: using an irq_work to delay the queuing of
> the work to start process_srcu().
>
> [boqun: Apply Joel's feedback]
> [boqun: Apply Andrea's test feedback]
>
> Reported-by: Andrea Righi <[email protected]>
> Closes: https://lore.kernel.org/all/abjzvz_tL_siV17s@gpd4/
> Fixes: commit c27cea4416a3 ("rcu: Re-implement RCU Tasks Trace in terms of SRCU-fast")
> Link: https://lore.kernel.org/rcu/[email protected]/ [1]
> Suggested-by: Zqiang <[email protected]>
> Tested-by: Andrea Righi <[email protected]>
> Signed-off-by: Boqun Feng <[email protected]>

Thanks for the patch, which is now upstream as
7c405fb3279b ("rcu: Use an intermediate irq_work to start process_srcu()")

Unfortunately it seems to halt booting on the Allwinner D1 single-core RISC-V
SoC both on the 7.0 and 7.1 kernels:

https://esmil.dk/d1-7.0.txt
https://esmil.dk/d1-7.1.txt

Reverting this patch seems to fix the issue although it then breaks when loading
modules which is can be fixed by reverting:
d6e152d905bd ("clockevents: Prevent timer interrupt starvation")

This might be a side-effect of reverting this patch though.

We'd really like to continue support for this SoC on the 7.0 kernel, but since
this patch is a bugfix just shippping the revert doesn't sound appealing.
So some guidance would be much appreciated, thanks!

/Emil