netdev - Re: [PATCH] net: Handle napi_schedule() calls from non-interrupt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z7i-_p_115kr8aj1@LQ3V64L9R2>
Date: Fri, 21 Feb 2025 12:59:26 -0500
From: Joe Damato <jdamato@...tly.com>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, netdev@...r.kernel.org,
	Breno Leitao <leitao@...ian.org>, Jakub Kicinski <kuba@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	Francois Romieu <romieu@...zoreil.com>,
	Paul Menzel <pmenzel@...gen.mpg.de>
Subject: Re: [PATCH] net: Handle napi_schedule() calls from non-interrupt

On Fri, Feb 21, 2025 at 06:30:09PM +0100, Frederic Weisbecker wrote:
> napi_schedule() is expected to be called either:
> 
> * From an interrupt, where raised softirqs are handled on IRQ exit
> 
> * From a softirq disabled section, where raised softirqs are handled on
>   the next call to local_bh_enable().
> 
> * From a softirq handler, where raised softirqs are handled on the next
>   round in do_softirq(), or further deferred to a dedicated kthread.
> 
> Other bare tasks context may end up ignoring the raised NET_RX vector
> until the next random softirq handling opportunity, which may not
> happen before a while if the CPU goes idle afterwards with the tick
> stopped.
> 
> Such "misuses" have been detected on several places thanks to messages
> of the kind:
> 
> 	"NOHZ tick-stop error: local softirq work is pending, handler #08!!!"

Might be helpful to include the stack trace of the offender you did
find which led to this change?

> Chasing each and every misuse can be a long journey given the amount of
> existing callers. Fixing them can also prove challenging if the caller
> may be called from different kind of context.

Any way to estimate how many misuses there are with coccinelle or
similar to get a grasp on the scope?

Based on the scope of the problem it might be better to fix the
known offenders and add a WARN_ON_ONCE or something instead of the
proposed change? Not sure, but having more information might help
make that determination.

> Therefore fix this from napi_schedule() itself with waking up ksoftirqd
> when softirqs are raised from task contexts.
> 
> Reported-by: Paul Menzel <pmenzel@...gen.mpg.de>
> Closes: 354a2690-9bbf-4ccb-8769-fa94707a9340@...gen.mpg.de

AFAIU, Closes tags should point to URLs not message IDs.

If this is a fix, the subject line should be:
   [PATCH net]

And there should be a Fixes tag referencing the SHA which caused the
issue and the patch should CC stable.

See:

https://www.kernel.org/doc/html/v6.13/process/maintainer-netdev.html#netdev-faq