netdev - Re: How to display IPv4 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] [thread-next>] [day] [month] [year] [list]

Date: Tue, 12 Mar 2024 13:12:30 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Hangbin Liu <liuhangbin@...il.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
	Donald Hunter <donald.hunter@...il.com>, netdev@...r.kernel.org
Subject: Re: How to display IPv4 array?

Tue, Mar 12, 2024 at 11:08:33AM CET, liuhangbin@...il.com wrote:
>Hi Jakub,
>
>I plan to add bond support for Documentation/netlink/specs/rt_link.yaml. While
>dealing with the attrs. I got a problem about how to show the bonding arp/ns
>targets. Because the arp/ns targets are filled as an array[1]. I tried
>something like:
>
>  -
>    name: linkinfo-bond-attrs
>    name-prefix: ifla-bond-
>    attributes:
>      -
>        name: arp-ip-target
>        type: nest
>        nested-attributes: ipv4-addr
>  -
>    name: ipv4-addr
>    attributes:
>      -
>        name: addr
>        type: binary
>        display-hint: ipv4
>
>But this failed with error: Exception: Space 'ipv4-addr' has no attribute with value '0'
>Do you have any suggestion?
>
>[1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/drivers/net/bonding/bond_netlink.c#n670

Yeah, that's odd use of attr type, here it is an array index. I'm pretty
sure I saw this in the past on different netlink places.
I believe that is not supported with the existing ynl code.

Perhaps something like the following might work:
      -
        name: arp-ip-target
        type: binary
        display-hint: ipv4
	nested-array: true

"nested-array" would tell the parser to expect a nest that has attr
type of value of array index, "type" is the same for all array members.
The output will be the same as in case of "multi-attr", array index
ignored (I don't see what it would be good for to the user).

Other existing attrs considered:

"nested-attributes" does not make much sense for this usecase IMO as the
attr type is array index, the mapping fails.

"multi-attr" also counts with valid attr type and no nest.

Makes sense?