Re: [PATCH v4 7/7] net: register debugfs file for net_device refcnt tracker

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 24 Apr 2025 14:10:03 +0200 Andrew Lunn wrote:
> > > > > How much naming the objects in a "user readable" fashion actually
> > > > > matter? It'd be less churn to create some kind of "object class"
> > > > > with a directory level named after what's already passed to
> > > > > ref_tracker_dir_init() and then id the objects by the pointer value 
> > > > > as sub-dirs of that?    
> > > > 
> > > > That sounds closer to what I had done originally. Andrew L. suggested
> > > > the flat directory that this version represents. I'm fine with whatever
> > > > hierarchy, but let's decide that before I respin again.  
> > > 
> > > Sorry about that :(
> > >   
> > 
> > No worries...but we do need to decide what this directory hierarchy
> > should look like.
> > 
> > Andrew's point earlier was that this is just debugfs, so a flat
> > "ref_tracker" directory full of files is fine. I tend to agree with
> > him; NAME_MAX is 255, so we have plenty of room to make uniquely-named
> > files.
> > 
> > We could build a dir hierarchy though. Something like:
> > 
> > - ref_tracker
> >     + netdev
> >     + netns  
> 
> How do you make that generic? How due the GPU users of reftracker fit
> in? And whatever the next users are? A flat directory keeps it
> simple. Anybody capable of actually using this has to have a level of
> intelligence sufficient for glob(3).
> 
> However, a varargs format function does make sense, since looking at
> the current users, many of them will need it.

No preference on my side about the hierarchy TBH. I just defaulted to
thinking about it in terms of a hierarchy class/id rather than class-id
but shouldn't matter.

The main point I was trying to make was about using a synthetic ID -
like the pointer value. For the netdevs this patchset waits until 
the very end of the registration process to add the debugfs dir
because (I'm guessing) the name isn't assigned when we alloc 
the device (and therefore when we call ref_tracker_dir_init()).

Using synthetic ID lets us register the debugfs from
ref_tracker_dir_init().

In fact using "registered name" can be misleading. In modern setups
where devices are renamed based on the system topology, after
registration.

The Ethernet interface on my laptop is called enp0s13f0u1u1,
not eth0. It is renamed by systemd right _after_ registration.

[45224.911324] r8152 2-1.1:1.0 eth0: v1.12.13
[45225.220032] r8152 2-1.1:1.0 enp0s13f0u1u1: renamed from eth0

so in (most?) modern systems the name we carefully printed
into the debugfs name will in fact not match the current device name.
What more we don't try to keep the IDs monotonically increasing. 
If I plug in another Ethernet card it will also be called eth0 when
it's registered, again. You can experiment by adding dummy devices:

# ip link add type dummy
# ip link
...
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether b2:51:ee:5b:4b:83 brd ff:ff:ff:ff:ff:ff

# ip link set dev dummy0 name other-name
[  206.747381][  T670] other-name: renamed from dummy0
# ip link
...
2: other-name: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether b2:51:ee:5b:4b:83 brd ff:ff:ff:ff:ff:ff

# ip link add type dummy
# ip link
...
2: other-name: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether b2:51:ee:5b:4b:83 brd ff:ff:ff:ff:ff:ff
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether b2:51:ee:5b:4b:83 brd ff:ff:ff:ff:ff:ff


The second device is called dummy0, again, because that name was
"free". So with the current code we delay the registration of debugfs
just to provide a name which is in fact misleading :S

But with all that said, I guess you still want the "meaningful" ID for
the netns, and that one is in fact stable :S