linux-debuggers.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Omar Sandoval <osandov@osandov.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Stephen Brennan <stephen.s.brennan@oracle.com>,
	Christian Brauner <brauner@kernel.org>,
	Mateusz Guzik <mjguzik@gmail.com>,
	linux-kernel@vger.kernel.org, linux-debuggers@vger.kernel.org,
	Sentaro Onizuka <sentaro@amazon.com>
Subject: Re: [PATCH] fs: convert mount flags to enum
Date: Wed, 7 May 2025 16:13:03 -0700	[thread overview]
Message-ID: <aBvo_-Ee7QQtd3YU@telecaster> (raw)
In-Reply-To: <20250507230511.GA2023217@ZenIV>

On Thu, May 08, 2025 at 12:05:11AM +0100, Al Viro wrote:
> On Wed, May 07, 2025 at 03:34:01PM -0700, Stephen Brennan wrote:
> > In prior kernel versions (5.8-6.8), commit 9f6c61f96f2d9 ("proc/mounts:
> > add cursor") introduced MNT_CURSOR, a flag used by readers from
> > /proc/mounts to keep their place while reading the file. Later, commit
> > 2eea9ce4310d8 ("mounts: keep list of mounts in an rbtree") removed this
> > flag and its value has since been repurposed.
> > 
> > For debuggers iterating over the list of mounts, cursors should be
> > skipped as they are irrelevant. Detecting whether an element is a cursor
> > can be difficult. Since the MNT_CURSOR flag is a preprocessor constant,
> > it's not present in debuginfo, and since its value is repurposed, we
> > cannot hard-code it. For this specific issue, cursors are possible to
> > detect in other ways, but ideally, we would be able to read the mount
> > flag definitions out of the debuginfo. For that reason, convert the
> > mount flags to an enum.
> 
> Just a warning - there's a bunch of pending changes in that area,
> so debuggers are going to be in trouble anyway.
> 
> Folks, VFS data structures do *NOT* come with any stability warranties.
> Especially if the object in question is not even defined in include/*/*...
> 
> _Anything_ that tries to play with these objects must be version-dependent
> and be ready to be broken by changes in underlying code at zero notice.

That's totally fine, we can deal with breakages as long as we can
reliably detect what version we're dealing with. We can see changed enum
values, renamed/removed structure members, etc., so that's why those are
preferable. Macros are invisible at the debug info level (since no one
compiles with -g3), so those are no good for us. We also avoid version
checks as much as possible because backports in RHEL and co. make
version numbers mostly meaningless.

  reply	other threads:[~2025-05-07 23:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-07 22:34 [PATCH] fs: convert mount flags to enum Stephen Brennan
2025-05-07 23:05 ` Al Viro
2025-05-07 23:13   ` Omar Sandoval [this message]
2025-05-07 23:44     ` Omar Sandoval
2025-05-09 11:17       ` Christian Brauner
2025-05-09 11:20 ` Christian Brauner

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=aBvo_-Ee7QQtd3YU@telecaster \
    --to=osandov@osandov.com \
    --cc=brauner@kernel.org \
    --cc=linux-debuggers@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjguzik@gmail.com \
    --cc=sentaro@amazon.com \
    --cc=stephen.s.brennan@oracle.com \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).