Message-ID: <d6efca57733c141c6fdfa39b402d05db8badb8c6.camel@kernel.org>
Date: Fri, 25 Apr 2025 08:46:17 -0400
From: Jeff Layton <jlayton@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>
Cc: Andrew Morton <akpm@...ux-foundation.org>, "David S. Miller"
	 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
	 <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, Kuniyuki Iwashima
	 <kuniyu@...zon.com>, Qasim Ijaz <qasdev00@...il.com>, Nathan Chancellor
	 <nathan@...nel.org>, linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v4 7/7] net: register debugfs file for net_device refcnt
 tracker

On Thu, 2025-04-24 at 15:52 -0700, Jakub Kicinski wrote:
> 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().
> 

Yes, exactly. dev->name doesn't get populated until later, so we have
to delay creating the debugfs file if we want the name to be
meaningful. Ditto for the netns and its inode number.

We certainly could move to "classname@%px" format. If we go that route,
I'd suggest that we convert the ref_tracker_dir.name field to a const
char * pointer, and have the ref_tracker_dir_init() callers pass in a
pointer to a static classname string. No need to keep copies in that
case. The i915 ref_trackers would need to be changed, but hopefully
that's not a problem.

With that change we could register the debugfs files in
ref_tracker_dir_init() instead of having an extra call. The caveat
there is that some of these objects get created very early (e.g.
init_net), before debugfs comes online, so we'll miss creating debugfs
files for those objects. Maybe that's no big deal.

> 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
> 

Lovely.

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

I would prefer that, but if that's not feasible then I can live without
meaningful names. We'd just have to determine some way to get the
address of a particular netns or netdev, which is an extra step when
debugging, but one we can do (e.g., with drgn).
-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists