netdev - Re: [PATCH] net/tun: expose queue utilization stats via ethtool

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: <68277463d4c43_2ba041294cf@willemb.c.googlers.com.notmuch>
Date: Fri, 16 May 2025 13:22:43 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Daniel Xu <dxu@...uu.xyz>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>, 
 Alexander Shalimov <alex-shalimov@...dex-team.ru>
Cc: andrew@...n.ch, 
 David Miller <davem@...emloft.net>, 
 Eric Dumazet <edumazet@...gle.com>, 
 jacob.e.keller@...el.com, 
 jasowang@...hat.com, 
 Jakub Kicinski <kuba@...nel.org>, 
 linux-kernel@...r.kernel.org, 
 netdev@...r.kernel.org, 
 Paolo Abeni <pabeni@...hat.com>, 
 "bpf@...r.kernel.org" <bpf@...r.kernel.org>
Subject: Re: [PATCH] net/tun: expose queue utilization stats via ethtool

Daniel Xu wrote:
> On Thu, May 15, 2025, at 7:12 AM, Willem de Bruijn wrote:
> > Alexander Shalimov wrote:
> >> 06.05.2025, 22:32, "Willem de Bruijn" <willemdebruijn.kernel@...il.com>:
> >> > Perhaps bpftrace with a kfunc at a suitable function entry point to
> >> > get access to these ring structures.
> >> 
> >> Thank you for your responses!
> >> 
> >> Initially, we implemented such monitoring using bpftrace but we were
> >> not satisfied with the need to double-check the structure definitions
> >> in tun.c for each new kernel version.
> >> 
> >> We attached kprobe to the "tun_net_xmit()" function. This function
> >> gets a "struct net_device" as an argument, which is then explicitly
> >> cast to a tun_struct - "struct tun_struct *tun = netdev_priv(dev)".
> >> However, performing such a cast within bpftrace is difficult because
> >> tun_struct is defined in tun.c - meaning the structure definition
> >> cannot be included directly (not a header file). As a result, we were
> >> forced to add fake "struct tun_struct" and "struct tun_file"
> >> definitions, whose maintenance across kernel versions became
> >> cumbersome (see below). The same problems exists even with kfunc and
> >> btf - we are not able to cast properly netdev to tun_struct.
> >> 
> >> That’s why we decided to add this functionality directly to the kernel.
> >
> > Let's solve this in bpftrace instead. That's no reason to rever to
> > hardcoded kernel APIs.
> >
> > It quite possibly already is. I'm no bpftrace expert. Cc:ing bpf@
> 
> Yeah, should be possible. You haven't needed to include header
> files to access type information available in BTF for a while now.
> This seems to work for me - mind giving this a try?
> 
> ```
> fentry:tun:tun_net_xmit {
>     $tun = (struct tun_struct *)args->dev->priv;
>     print($tun->numqueues);  // or whatever else you want
> }
> ```
> 
> fentry probes are better in general than kprobes if all you're doing
> is attaching to the entry of a function.
> 
> You could do the same with kprobes like this if you really want, though:
> 
> ```
> kprobe:tun:tun_net_xmit {
>     $dev = (struct net_device *)arg1;
>     $tun = (struct tun_struct *)$dev->priv;
>     print($tun->numqueues);  // or whatever else you want
> }
> ```
> 
> Although it looks like there's a bug when you omit the module name
> where bpftrace doesn't find the struct definition. I'll look into that.

Minor: unless tun is built-in.

Thanks a lot for your response, Daniel. Good to know that we can get
this information without kernel changes. And I learned something new
:) Replicated your examples.