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: <582527ed-802b-f20e-4c50-f6f2ba460c4c@gmail.com>
Date: Thu, 27 Jun 2024 15:24:57 +0100
From: Edward Cree <ecree.xilinx@...il.com>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>, edward.cree@....com
Cc: linux-net-drivers@....com, netdev@...r.kernel.org,
 habetsm.xilinx@...il.com, sudheer.mogilappagari@...el.com,
 jdamato@...tly.com, mw@...ihalf.com, linux@...linux.org.uk,
 sgoutham@...vell.com, gakula@...vell.com, sbhatta@...vell.com,
 hkelam@...vell.com, saeedm@...dia.com, leon@...nel.org,
 jacob.e.keller@...el.com, andrew@...n.ch, ahmed.zaki@...el.com,
 davem@...emloft.net, kuba@...nel.org, edumazet@...gle.com, pabeni@...hat.com
Subject: Re: [PATCH v6 net-next 3/9] net: ethtool: record custom RSS contexts
 in the XArray

On 26/06/2024 10:05, Przemek Kitszel wrote:
> On 6/25/24 15:39, Edward Cree wrote:
>> On 20/06/2024 07:32, Przemek Kitszel wrote:
>>> why no error code set?
>>
>> Because at this point the driver *has* created the context, it's
>>   in the hardware.  If we wanted to return failure we'd have to
>>   call the driver again to delete it, and that would still leave
>>   an ugly case where that call fails.
> 
> driver is creating both HW context and ID at the same time, after
> you call it from ethtool, eh :(
> 
> then my only concern is why do we want to keep old context instead of
> update? (my only and last concern for this series by now)
> say dumb driver always says "ctx=1" because it does not now better,
> but wants to update the context

Tbh I'm not sure there's a clear case either way, if driver is
 screwing up we don't know why or how.  The old context could
 still be present too for all we know.  So my preference is to
 say "we don't know what happened, let's just not touch the
 xarray at all".
In any case the WARN_ON should hopefully quickly catch any
 drivers that are hitting this, and going forward new drivers
 using this API shouldn't get added.

If you still feel strongly this should be changed, please
 elaborate further on the reasoning.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ