netdev - Re: [PATCH bpf-next 1/3] netkit: Allow for configuring needed

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: <7c6fab5a-8925-4be6-8c1c-2d0a4fcc3585@iogearbox.net>
Date: Sat, 21 Dec 2024 01:04:52 +0100
From: Daniel Borkmann <daniel@...earbox.net>
To: Jakub Kicinski <kuba@...nel.org>
Cc: martin.lau@...ux.dev, razor@...ckwall.org, pabeni@...hat.com,
 bpf@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH bpf-next 1/3] netkit: Allow for configuring
 needed_{head,tail}room

On 12/20/24 10:06 AM, Daniel Borkmann wrote:
> On 12/20/24 3:23 AM, Jakub Kicinski wrote:
>> On Thu, 19 Dec 2024 18:39:26 +0100 Daniel Borkmann wrote:
>>> +    if (headroom) {
>>> +        peer->needed_headroom = headroom;
>>> +        dev->needed_headroom = headroom;
>>> +    }
>>> +    if (tailroom) {
>>> +        peer->needed_tailroom = tailroom;
>>> +        dev->needed_tailroom = tailroom;
>>> +    }
>>
>> Since you use the same one for main dev and peer should there be
>> something rejecting the use of the new attr in the peer attrs?
>> (IFLA_NETKIT_PEER_INFO)
> 
> The peer info is parsed via rtnl_nla_parse_ifinfomsg() which internally
> uses ifla_policy filter where IFLA_INFO_DATA is not part of, but to be
> sure I can add one more selftest case to confirm.

Looks like we don't bail out anymore after the conversion in fefd5d082172
("netkit: Set IFLA_NETKIT_PEER_INFO to netkit_link_ops.peer_type."), so I
left it out for now from the series.. need to experiment some more whether
fefd5d082172 dropping the error has any unintended side-effects. But I'm
currently not seeing how it would be much different to, for example, the
preceding netif_inherit_tso_max() call.

Thanks,
Daniel