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

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.