linux-kernel - Re: [PATCH net v2] 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] [day] [month] [year] [list]

Message-ID: <20250305085249.j11kJDkC@linutronix.de>
Date: Wed, 5 Mar 2025 09:52:49 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Frederic Weisbecker <frederic@...nel.org>,
	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>,
	Paolo Abeni <pabeni@...hat.com>,
	Francois Romieu <romieu@...zoreil.com>,
	Paul Menzel <pmenzel@...gen.mpg.de>,
	Joe Damato <jdamato@...tly.com>
Subject: Re: [PATCH net v2] net: Handle napi_schedule() calls from
 non-interrupt

On 2025-02-26 14:34:39 [+0100], Eric Dumazet wrote:
> On Wed, Feb 26, 2025 at 2:21 PM Frederic Weisbecker <frederic@...nel.org> wrote:
> >
> 
> > That looks good and looks like what I did initially:
> >
> > https://lore.kernel.org/lkml/20250212174329.53793-2-frederic@kernel.org/
> >
> > Do you prefer me doing it over DEBUG_NET_WARN_ON_ONCE() or with lockdep
> > like in the link?
> 
> To be clear, I have not tried this thing yet.
> 
> Perhaps let your patch as is (for stable backports), and put the debug
> stuff only after some tests, in net-next.
> 
> It is very possible that napi_schedule() in the problematic cases were
> not on a fast path anyway.

I got here via Sascha's stable backports. It looks to me that these
paths (the reported once) are not widely tested and then we don't have
any prints if the BH section is missing while expected.

Would it work for everyone if warnings are added and this patch is
reverted? These days ksoftirqd is not blocking any softirqs until it run
so chances are that the NAPI softirq kicks in before ksoftirqd gets on
the CPU so the damage is probably little.

I am slightly undecided here since real work usually originates in
softirq and it is hard to get this wrong but then who knows…

> Reviewed-by: Eric Dumazet <edumazet@...gle.com>

Sebastian