linux-kernel - Re: [PATCH net-next 0/7] ynl: add ignore-index flag for indexed-array

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: <20251023170342.2bb7ce83@kernel.org>
Date: Thu, 23 Oct 2025 17:03:42 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Asbjørn Sloth Tønnesen
 <ast@...erby.net>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Chia-Yu Chang
 <chia-yu.chang@...ia-bell-labs.com>, Chuck Lever <chuck.lever@...cle.com>,
 Donald Hunter <donald.hunter@...il.com>, Jonathan Corbet <corbet@....net>,
 "Matthieu Baerts (NGI0)" <matttbe@...nel.org>, Simon Horman
 <horms@...nel.org>, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 0/7] ynl: add ignore-index flag for
 indexed-array

On Thu, 23 Oct 2025 18:37:09 +0000 Asbjørn Sloth Tønnesen wrote:
>  > C code already does this, right? We just collect the attributes
>  > completely ignoring the index.  
> 
> In the userspace C code, for sub-type nest the index is preserved
> in struct member idx, and elided for other sub-types.

I see it now, I guess I added it for get but forgot to obey it 
for put :(

>  > So why do we need to extend the spec.  
> 
> For me it's mostly the naming "indexed-array". Earlier it was
> "array-nest", then we renamed it to "indexed-array" because
> it doesn't always contain nests.  I think it's counter-intuitive
> to elide the index by default, for something called "indexed-array".
> The majority of the families using it don't care about the index.
> 
> What if we called it "ordered-array", and then always counted from 1
> (for families that cares) when packing in user-space code?
> 
>  > Have you found any case where the index matters and can be
>  > non-contiguous (other than the known TC kerfuffle).  
> 
> IFLA_OFFLOAD_XSTATS_HW_S_INFO could be re-defined as a nest,
> IFLA_OFFLOAD_XSTATS_L3_STATS is the only index atm.

Isn't that pretty much always true? If the index is significant
the whole thing could be redefined as a nest, with names provided
in the spec?

> IFLA_INET_CONF / IFLA_INET6_CONF is on input, but those are
> also special by having different types depending on direction.
> 
> I found a bunch of other ones, using a static index, but they
> can also be defined as a multi-attr wrapped in an additional
> outer nest, like IFLA_VF_VLAN_LIST already is.

Multi-attr with an outer nest should at least solve your wg problem 
I guess? If all the attrs have type of 0 we can make it a multi-attr.

>  > FWIW another concept is what TypeValue does.
>  > "Inject" the index into the child nest as an extra member.
>  > Most flexible but also prolly a PITA for user space to init those
>  > for requests.  
> 
> Same as is done in the userspace C code for indexed-arrays with
> sub-type nest. For most families it doesn't matter if the C code
> inits the index or not.