linux-kernel - 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: <0bcc08e4-9f22-431c-97f3-c7d5784d2652@app.fastmail.com>
Date: Thu, 15 May 2025 18:56:34 -0700
From: "Daniel Xu" <dxu@...uu.xyz>
To: "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

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.

Thanks,
Daniel