netdev - Re: [PATCH net-next v3 03/15] net: Add peer info to queue-get response

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: <17f5b871-9bd9-4313-b123-67afa0f69272@iogearbox.net>
Date: Fri, 24 Oct 2025 14:59:39 +0200
From: Daniel Borkmann <daniel@...earbox.net>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, bpf@...r.kernel.org, davem@...emloft.net,
 razor@...ckwall.org, pabeni@...hat.com, willemb@...gle.com, sdf@...ichev.me,
 john.fastabend@...il.com, martin.lau@...nel.org, jordan@...fe.io,
 maciej.fijalkowski@...el.com, magnus.karlsson@...el.com, dw@...idwei.uk,
 toke@...hat.com, yangzhenze@...edance.com, wangdongdong.6@...edance.com
Subject: Re: [PATCH net-next v3 03/15] net: Add peer info to queue-get
 response

On 10/24/25 4:33 AM, Jakub Kicinski wrote:
> On Mon, 20 Oct 2025 18:23:43 +0200 Daniel Borkmann wrote:
>> Add a nested peer field to the queue-get response that returns the peered
>> ifindex and queue id.
>>
>> Example with ynl client:
>>
>>    # ip netns exec foo ./pyynl/cli.py \
>>        --spec ~/netlink/specs/netdev.yaml \
>>        --do queue-get \
>>        --json '{"ifindex": 3, "id": 1, "type": "rx"}'
>>    {'id': 1, 'ifindex': 3, 'peer': {'id': 15, 'ifindex': 4, 'netns-id': 21}, 'type': 'rx'}
> 
> I'm struggling with the roles of what is src and dst and peer :(
> No great suggestion off the top of my head but better terms would
> make this much easier to review.
> 
> The example seems to be from the container side. Do we need to show peer
> info on the container side? Not just on the host side?

I think up to us which side we want to show. My thinking was to allow user
introspection from both, but we don't have to. Right now the above example
was from the container side, but technically it could be either side depending
in which netns the phys dev would be located.

The user knows which is which based on the ifindex passed to the queue-get
query: if the ifindex is from a virtual device (e.g. netkit type), then the
'peer' section shows the phys dev, and vice versa, if the ifindex is from a
phys device (say, mlx5), then the 'peer' section shows the virtual one.

Maybe I'll provide a better more in-depth example with both sides and above
explanation in the commit msg for v4..

Thanks,
Daniel