Re: Backport request: Revert "softirq: Let ksoftirqd do its job" (d15121be7485)

[Jason Xing]

Hi Paolo,

On Thu, Oct 29, 2026 at 4:33 PM Paolo Abeni <pabeni@xxxxxxxxxx> wrote:
>
> On 10/29/26 06:42, Gyutae Bae wrote:
> > Please backport the following upstream commit to 6.1.y and 5.15.y:
> >
> >    d15121be7485655129101f3960ae6add40204463
> >    Revert "softirq: Let ksoftirqd do its job"
> >
> > On a production 5.15 PREEMPT_NONE node, long-running overlayfs
> > getdents64() calls prevented ksoftirqd from running.  RPS IPIs
> > continued to arrive, but NET_RX processing on that CPU stalled for
> > up to about 3 seconds.  Over 15 days, the node logged about 1,000
> > bonding ARP monitor failovers, with no link-state changes recorded
> > during that period.  The failovers stopped after the workload was
> > removed.
> >
> > On a 5.15.27 PREEMPT_NONE test node, we used a livepatch to make
> > ksoftirqd_running() always return false.  This removes the same
> > softirq deferral checks as the revert on this build.  Under the same
> > load, we measured three 10-minute windows: before patching, with the
> > livepatch active, and after removing it.  The number of HTTP requests
> > taking more than 200 ms was 17, 0 and 11, respectively.  TCPTimeouts
> > increased by 25, 1 and 21.
> >
> > We verified with patch --dry-run that the revert applies cleanly
> > to v6.1.190 and v5.15.223.  Both already contain the related RCU
> > fix 1dd1eff161bd.  6.6.y and later already contain the revert.
> >
> > The original commit was intended to prevent user-task starvation
> > under a softirq flood.  The revert's changelog points to threaded
> > NAPI as an alternative, but it is disabled by default.
> >
> > The revert was merged in v6.5 without a Cc: stable tag.
> > Syzbot has also reported bisections to this revert [1].
> > Paolo, Thomas, Eric: I would appreciate your thoughts on whether
> > this revert is suitable for 6.1.y and 5.15.y.
> >
> > [1] https://lore.kernel.org/all/000000000000a249880603717c15@xxxxxxxxxx/
> IMHO such change should not land to stable lightly. It's a behavioural
> change with subtle side effects. The threaded napi feature is disabled

Technically speaking, yes, it's actually not a bug but an optimization.

> by default for the same reason. Also the revert has some soft functional
> dependencies in napi threaded cleanup and improvements landed into v6.4,
> i.e. 6bb218b5a6e3f3c5e2e76faf8fc976f3f6f72496, likely more.

Maybe I have a slightly different thought on this: since I really
received/noticed there are not a few reports showing the 'issue' in
the older kernels. It's not easy for some people or company to upgrade
the stable kernel. I'm wondering if it's still possible to land it
with more careful consideration in the patch if Gyutae volunteers to
do so? Please feel free to reject the proposal :)

Thanks,
Jason