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: <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/ 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ