netdev - Re: [PATCH net-next v6] Add support to set napi threaded for individual napi

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: <aBJntw1WwxxFJ9e2@LQ3V64L9R2>
Date: Wed, 30 Apr 2025 11:11:03 -0700
From: Joe Damato <jdamato@...tly.com>
To: Samiullah Khawaja <skhawaja@...gle.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
	"David S . Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	almasrymina@...gle.com, willemb@...gle.com, mkarsten@...terloo.ca,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next v6] Add support to set napi threaded for
 individual napi

On Wed, Apr 30, 2025 at 10:54:16AM -0700, Samiullah Khawaja wrote:

> Also please note the discussion on stopping the thread I shared earlier:
> https://lore.kernel.org/netdev/CAKgT0UdjWGBrv9wOUyOxon5Sn7qSBHL5-KfByPS4uB1_TJ3WiQ@mail.gmail.com/

In the thread you linked, you'll see that Jakub said this should probably be
fixed in the future:

  Can we put a note in the commit message saying that stopping the
  threads is slightly tricky but we'll do it if someone complains?

So, this suggests, again, that this need to be fixed and Jakub
already addressed how things have changed which would make this
easier in [3]:

  > We should check the discussions we had when threaded NAPI was added.
  > I feel nothing was exposed in terms of observability so leaving the
  > thread running didn't seem all that bad back then. Stopping the NAPI
  > polling safely is not entirely trivial, we'd need to somehow grab
  > the SCHED bit like busy polling does, and then re-schedule.
  > Or have the thread figure out that it's done and exit.
  
  Actually, we ended up adding the explicit ownership bits so it may not
  be all that hard any more.. Worth trying.

So based on all of the messages in the v5 and in the past, it seems pretty
clear to me that this needs to be fixed.

[3]: https://lore.kernel.org/netdev/20250425201220.58bf25d7@kernel.org/