public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	 Jakub Kicinski	 <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman	 <horms@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
		netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] net: add debugfs files for showing netns refcount tracking info
Date: Thu, 10 Apr 2025 10:41:13 -0400	[thread overview]
Message-ID: <b2183fb18102b99685b69d57cb099995364c68c8.camel@kernel.org> (raw)
In-Reply-To: <f4722246-5694-4b1a-9b1b-d4352fa54ee7@lunn.ch>

On Thu, 2025-04-10 at 16:12 +0200, Andrew Lunn wrote:
> > Oh, ok. I guess you mean these names?
> > 
> >         ref_tracker_dir_init(&net->refcnt_tracker, 128, "net refcnt");
> >         ref_tracker_dir_init(&net->notrefcnt_tracker, 128, "net notrefcnt");
> > 
> > Two problems there:
> > 
> > 1/ they have an embedded space in the name which is just painful. Maybe we can replace those with underscores?
> > 2/ they aren't named in a per-net namespace way
> 
> So the first question is, are the names ABI? Are they exposed to
> userspace anywhere? Can we change them?
> 
> If we can change them, space to _ is a simple change. Another option
> is what hwmon does, hwmon_sanitize_name() which turns a name into
> something which is legal in a filesystem. If all of this code can be
> pushed into the core tracker, so all trackers appear in debugfs, such
> a sanitiser is the way i would go.
> 
> And if we can change the name, putting the netns into the name would
> also work. There is then no need for the directory, if they have
> unique names.

AFAICT, they only show up today in some of the pr_ostream() error
messages. I'm assuming that means that they aren't part of ABI.

If we can change those names, then we could just make the debugfs file
registrations happen as part of ref_tracker_dir_init() under a flat
hierarchy like you suggest. If that's the case I can move the whole
thing into ref_tracker.c.

I'd probably shoot to just ensure that the names unique in some fashion
rather than try to run them through a sanitizer.

Eric any thoughts, re: ABI?

> Looking at other users of ref_tracker_dir_init():
> 
> ~/linux$ grep -r ref_tracker_dir_init
> lib/test_ref_tracker.c:	ref_tracker_dir_init(&ref_dir, 100, "selftest");
> 
> Can only be loaded once, so is unique.
> 
> drivers/gpu/drm/i915/intel_wakeref.c:	ref_tracker_dir_init(&wf->debug, INTEL_REFTRACK_DEAD_COUNT, name);
> 
> Looks like it is unique for one GPU, but if you have multiple GPUs
> they are not unique.
> 
> drivers/gpu/drm/i915/intel_runtime_pm.c:	ref_tracker_dir_init(&rpm->debug, INTEL_REFTRACK_DEAD_COUNT, dev_name(rpm->kdev));
> 
> At a guess kdev is unique.
> 
> drivers/gpu/drm/display/drm_dp_tunnel.c:	ref_tracker_dir_init(&mgr->ref_tracker, 16, "dptun");
> 
> Probably not unique.
> 
> net/core/net_namespace.c:	ref_tracker_dir_init(&net->refcnt_tracker, 128, "net refcnt");
> net/core/net_namespace.c:	ref_tracker_dir_init(&net->notrefcnt_tracker, 128, "net notrefcnt");
> 
> Not unique across name spaces, but ...
> 
> So could the tracker core check if the debugfs file already exists,
> emit a warning if it does, and keep going? I think debugfs_lookup()
> will tell you if a file already exists, or debugfs_create_file() will
> return -EEXIST, which is probably safer, no race condition.

Yeah, that would work. If we get back an EEXIST, we can throw a
pr_notice or something too. That probably means the name wasn't
sufficiently unique.

I'll work on a v3 that moves things in that direction.

Thanks for the review!
-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2025-04-10 14:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-08 13:36 [PATCH v2 0/2] net: add debugfs files for showing netns refcount tracking info Jeff Layton
2025-04-08 13:36 ` [PATCH v2 1/2] ref_tracker: add a top level debugfs directory for ref_tracker Jeff Layton
2025-04-10  4:27   ` Kuniyuki Iwashima
2025-04-10 12:05   ` Andrew Lunn
2025-04-08 13:36 ` [PATCH v2 2/2] net: add debugfs files for showing netns refcount tracking info Jeff Layton
2025-04-10  4:24   ` Kuniyuki Iwashima
2025-04-10 12:36   ` Andrew Lunn
2025-04-10 13:08     ` Jeff Layton
2025-04-10 13:23       ` Jeff Layton
2025-04-10 14:12         ` Andrew Lunn
2025-04-10 14:41           ` Jeff Layton [this message]
2025-04-13 11:40           ` Jeff Layton
2025-04-13 19:32             ` Andrew Lunn
2025-04-14 12:20               ` Jeff Layton
2025-04-14 12:46                 ` Andrew Lunn
2025-04-14 12:48                   ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b2183fb18102b99685b69d57cb099995364c68c8.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox