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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251029154730.1a0ac990@kernel.org>
Date: Wed, 29 Oct 2025 15:47:30 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: David Wei <dw@...idwei.uk>
Cc: Daniel Borkmann <daniel@...earbox.net>, 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, 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 Tue, 28 Oct 2025 19:08:10 -0700 David Wei wrote:
> >> 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..  
> > 
> > Yes, FWIW my mental model is that "leaking" host information into the
> > container is best avoided. Not a problem, but shouldn't be done without
> > a clear reason.
> > Typical debug scenario can be covered from the host side (container X
> > is having issues with queue Y, dump all the queues, find out which one
> > is bound to X/Y).  
> 
> Makes sense, I didn't consider leaking host info in a container. Happy
> to remove the introspection from the container side, leaving it only on
> the host side when queues are dumped.
> 
> Like Daniel mentioned, I didn't add 'src/real' or 'dst/virtual' because
> I believed this information is implicit to the user when querying a
> netdev based on its type. Do you find this to be confusing? Happy to add
> a clarifying field in the nested struct.

In veth/netkit we call "peer" the other side of an equal pipe. Same for
ndo_get_peer_dev. Queue is not a peering situation, but rather an attachment
/ delegation of a sub-object from one netdev to another.

I'd use a term like delegation or grant when talking about the HW
queue. And assignment in context of virtual.