Re: [PATCH] fs: convert mount flags to enum

[Christian Brauner <brauner@kernel.org>]

On Wed, May 07, 2025 at 04:44:31PM -0700, Omar Sandoval wrote:
> On Wed, May 07, 2025 at 04:13:03PM -0700, Omar Sandoval wrote:
> > 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.
> 
> To clarify, we avoid version _number_ checks (i.e., `if (kernel_version
> >= 6.15)`) as much as possible. "Version checks" in general are
> unavoidable, but in drgn, we try to base them on the existence of
> structure members, global variables, types, enum values, etc.

Yeah, that should be fine imho. I know that you're aware that we give no
stability guarantees but drgn is actively used by kernel developers and
that's a change we can accept without a lot of trouble for ourselves.