include/linux/mount.h | 87 ++++++++++++++++++++++--------------------- 1 file changed, 45 insertions(+), 42 deletions(-)
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.
Link: https://github.com/osandov/drgn/pull/496
Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
---
include/linux/mount.h | 87 ++++++++++++++++++++++---------------------
1 file changed, 45 insertions(+), 42 deletions(-)
diff --git a/include/linux/mount.h b/include/linux/mount.h
index dcc17ce8a959e..6904ad33ee7a3 100644
--- a/include/linux/mount.h
+++ b/include/linux/mount.h
@@ -22,48 +22,51 @@ struct fs_context;
struct file;
struct path;
-#define MNT_NOSUID 0x01
-#define MNT_NODEV 0x02
-#define MNT_NOEXEC 0x04
-#define MNT_NOATIME 0x08
-#define MNT_NODIRATIME 0x10
-#define MNT_RELATIME 0x20
-#define MNT_READONLY 0x40 /* does the user want this to be r/o? */
-#define MNT_NOSYMFOLLOW 0x80
-
-#define MNT_SHRINKABLE 0x100
-#define MNT_WRITE_HOLD 0x200
-
-#define MNT_SHARED 0x1000 /* if the vfsmount is a shared mount */
-#define MNT_UNBINDABLE 0x2000 /* if the vfsmount is a unbindable mount */
-/*
- * MNT_SHARED_MASK is the set of flags that should be cleared when a
- * mount becomes shared. Currently, this is only the flag that says a
- * mount cannot be bind mounted, since this is how we create a mount
- * that shares events with another mount. If you add a new MNT_*
- * flag, consider how it interacts with shared mounts.
- */
-#define MNT_SHARED_MASK (MNT_UNBINDABLE)
-#define MNT_USER_SETTABLE_MASK (MNT_NOSUID | MNT_NODEV | MNT_NOEXEC \
- | MNT_NOATIME | MNT_NODIRATIME | MNT_RELATIME \
- | MNT_READONLY | MNT_NOSYMFOLLOW)
-#define MNT_ATIME_MASK (MNT_NOATIME | MNT_NODIRATIME | MNT_RELATIME )
-
-#define MNT_INTERNAL_FLAGS (MNT_SHARED | MNT_WRITE_HOLD | MNT_INTERNAL | \
- MNT_DOOMED | MNT_SYNC_UMOUNT | MNT_MARKED)
-
-#define MNT_INTERNAL 0x4000
-
-#define MNT_LOCK_ATIME 0x040000
-#define MNT_LOCK_NOEXEC 0x080000
-#define MNT_LOCK_NOSUID 0x100000
-#define MNT_LOCK_NODEV 0x200000
-#define MNT_LOCK_READONLY 0x400000
-#define MNT_LOCKED 0x800000
-#define MNT_DOOMED 0x1000000
-#define MNT_SYNC_UMOUNT 0x2000000
-#define MNT_MARKED 0x4000000
-#define MNT_UMOUNT 0x8000000
+enum mount_flags {
+ MNT_NOSUID = 0x01,
+ MNT_NODEV = 0x02,
+ MNT_NOEXEC = 0x04,
+ MNT_NOATIME = 0x08,
+ MNT_NODIRATIME = 0x10,
+ MNT_RELATIME = 0x20,
+ MNT_READONLY = 0x40, /* does the user want this to be r/o? */
+ MNT_NOSYMFOLLOW = 0x80,
+
+ MNT_SHRINKABLE = 0x100,
+ MNT_WRITE_HOLD = 0x200,
+
+ MNT_SHARED = 0x1000, /* if the vfsmount is a shared mount */
+ MNT_UNBINDABLE = 0x2000, /* if the vfsmount is a unbindable mount */
+
+ MNT_INTERNAL = 0x4000,
+
+ MNT_LOCK_ATIME = 0x040000,
+ MNT_LOCK_NOEXEC = 0x080000,
+ MNT_LOCK_NOSUID = 0x100000,
+ MNT_LOCK_NODEV = 0x200000,
+ MNT_LOCK_READONLY = 0x400000,
+ MNT_LOCKED = 0x800000,
+ MNT_DOOMED = 0x1000000,
+ MNT_SYNC_UMOUNT = 0x2000000,
+ MNT_MARKED = 0x4000000,
+ MNT_UMOUNT = 0x8000000,
+
+ /*
+ * MNT_SHARED_MASK is the set of flags that should be cleared when a
+ * mount becomes shared. Currently, this is only the flag that says a
+ * mount cannot be bind mounted, since this is how we create a mount
+ * that shares events with another mount. If you add a new MNT_*
+ * flag, consider how it interacts with shared mounts.
+ */
+ MNT_SHARED_MASK = MNT_UNBINDABLE,
+ MNT_USER_SETTABLE_MASK = MNT_NOSUID | MNT_NODEV | MNT_NOEXEC
+ | MNT_NOATIME | MNT_NODIRATIME | MNT_RELATIME
+ | MNT_READONLY | MNT_NOSYMFOLLOW,
+ MNT_ATIME_MASK = MNT_NOATIME | MNT_NODIRATIME | MNT_RELATIME,
+
+ MNT_INTERNAL_FLAGS = MNT_SHARED | MNT_WRITE_HOLD | MNT_INTERNAL |
+ MNT_DOOMED | MNT_SYNC_UMOUNT | MNT_MARKED,
+};
struct vfsmount {
struct dentry *mnt_root; /* root of the mounted tree */
--
2.43.5On Wed, 07 May 2025 15:34:01 -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.
>
> [...]
Applied to the vfs-6.16.mount.api branch of the vfs/vfs.git tree.
Patches in the vfs-6.16.mount.api branch should appear in linux-next soon.
Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.
It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.
Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs-6.16.mount.api
[1/1] fs: convert mount flags to enum
https://git.kernel.org/vfs/vfs/c/6a8dcdd969cb
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.
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.
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.
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.
© 2016 - 2025 Red Hat, Inc.