netdev - Re: [PATCH net-next v6 1/7] net: ethtool: pass ethtool_rxfh to get/set

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]

Date: Mon, 3 Jun 2024 19:54:49 +0100
From: Edward Cree <ecree.xilinx@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Ahmed Zaki <ahmed.zaki@...el.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v6 1/7] net: ethtool: pass ethtool_rxfh to
 get/set_rxfh ethtool ops

On 27/11/2023 18:04, Jakub Kicinski wrote:
> On Mon, 27 Nov 2023 17:10:37 +0000 Edward Cree wrote:
>> Yep, I had noticed.  Was wondering how the removal of the old
>>  [sg]et_rxfh_context functions would interact with my new API,
>>  which has three ops (create/modify/delete) and thus can't
>>  really be wedged into the [sg]et_rxfh() like that.
> 
> Set side looks fairly straightforward. Get is indeed more tricky.
Looking at this now, and wondering if the create/modify/delete
 ops should use Ahmed's struct ethtool_rxfh_param, or keep the
 separated out fields (indir, key, hfunc, and now xfrm) as in
 my previous versions.
Arguments for keeping the separate arguments:
* Ensures that if the API is further extended (e.g. another
  parameter added, like input_xfrm was) then old drivers will
  refuse to build until fixed, rather than potentially silently
  ignoring new members of struct ethtool_rxfh_param.
* Avoids potential confusion by driver developers seeing the
  @indir_size, @key_size, and @rss_delete members of struct
  ethtool_rxfh_param, which are all superseded by or at least
  duplicative with parts of the new API (struct
  ethtool_rxfh_context has @indir_size and @key_size members;
  the separate 'delete' op in the new API obviates the need
  for a 'delete' flag).
However, you presumably had reasons for wanting the arguments
 wrapped in a struct in the first place, and they may still
 apply to the new API.  Guidance & comments would be welcome.

-ed