Re: [PATCH stable v5.15,v6.1] Revert "wireguard: device: enable threaded NAPI"

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Feb 17, 2026 at 12:01:15PM +0100, Daniel Borkmann wrote:
> On 2/17/26 11:33 AM, Greg KH wrote:
> > On Mon, Feb 16, 2026 at 10:33:53PM +0100, Jason A. Donenfeld wrote:
> > > On Mon, Feb 16, 2026 at 10:31 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> > > > Technically, the backport of commit db9ae3b6b43c ("wireguard: device:
> > > > enable threaded NAPI") to stable should not have happened since it is
> > > > more of an optimization rather than a pure fix and addresses a NAPI
> > > > situation with utilizing many WireGuard tunnel devices in parallel.
> > > 
> > > Indeed.
> > > 
> > > > Revert it from stable given the backport triggers a regression for
> > > > mentioned kernels.
> > > 
> > > Thanks.
> > > 
> > > Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
> > > 
> > > If that helps with Greg queueing this up.
> > 
> > I'll go queue it up now, thanks for the revert.  But it's ok being in
> > the 6.6.y and 6.12.y and newer kernels, right?
> Great question; from a stable kernel PoV that commit to enable threaded
> NAPI for wireguard by default went in natively (aka not via backports) in
> linux-6.18.y branch.
> 
> Given there have been backports around threaded NAPI and then reverts again
> e.g. [0-2] I think it would be best to also queue this revert here for 6.6.y
> and 6.12.y stable kernels. The same applies that it's more of an optimization
> rather than a pure fix.
> 
> I've added CF folks to Cc given they have been testing v6.6 with [2] but
> then it later got reverted again in [1] upon request. Feel free to holler
> if you think otherwise.
> 
> Thanks,
> Daniel
> 
>   [0] https://lore.kernel.org/netdev/CA+wXwBTT74RErDGAnj98PqS=wvdh8eM1pi4q6tTdExtjnokKqA@mail.gmail.com/
>   [1] https://lore.kernel.org/stable/20260204143848.216983148@linuxfoundation.org/
>   [2] https://lore.kernel.org/all/20260120103833.4kssDD1Y@linutronix.de/
> 

Ok, to be "safe", I'll queue this revert up for those other kernel
branches as well, thanks!  Worst case, we get someone who asks for it to
come back :)

thanks,

greg k-h