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: <7ac46cf3f626478d894da6b633f844b9@amazon.com>
Date: Thu, 9 May 2024 07:25:52 +0000
From: "Arinzon, David" <darinzon@...zon.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: David Miller <davem@...emloft.net>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "Woodhouse, David" <dwmw@...zon.co.uk>, "Machulsky,
 Zorik" <zorik@...zon.com>, "Matushevsky, Alexander" <matua@...zon.com>,
	"Bshara, Saeed" <saeedb@...zon.com>, "Wilson, Matt" <msw@...zon.com>,
	"Liguori, Anthony" <aliguori@...zon.com>, "Bshara, Nafea" <nafea@...zon.com>,
	"Belgazal, Netanel" <netanel@...zon.com>, "Saidi, Ali" <alisaidi@...zon.com>,
	"Herrenschmidt, Benjamin" <benh@...zon.com>, "Kiyanovski, Arthur"
	<akiyano@...zon.com>, "Dagan, Noam" <ndagan@...zon.com>, "Agroskin, Shay"
	<shayagr@...zon.com>, "Itzko, Shahar" <itzko@...zon.com>, "Abboud, Osama"
	<osamaabb@...zon.com>, "Ostrovsky, Evgeny" <evostrov@...zon.com>, "Tabachnik,
 Ofir" <ofirt@...zon.com>
Subject: RE: [PATCH v1 net-next 6/6] net: ena: Add a field for no interrupt
 moderation update action

> > This is a true/false indicator, it doesn't require history/previous value to be considered.
> > Therefore, not sure I see the how |= can help us in the logic here.
> > The flag is set here to true if during the interrupt moderation
> > update, which is, in this flow, triggered by an ethtool operation, the
> > moderation value has changed from the currently configurated one.
> 
> I couldn't locate an immediate application of the new value in the ethtool
> flow. So the question is whether the user can call update back to back, with
> the same settings. First time flag would be set and second time cleared.
> 
> Also the whole thing appears to be devoid of locking or any consideration of
> concurrency.

Hi Jakub,

I agree with your points, thank you for identifying them.
Will send a revised version of the logic in v2.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ