linux-kernel - Re: [PATCH] fs: convert mount flags to enum

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250507230511.GA2023217@ZenIV>
Date: Thu, 8 May 2025 00:05:11 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Stephen Brennan <stephen.s.brennan@...cle.com>
Cc: Christian Brauner <brauner@...nel.org>,
	Mateusz Guzik <mjguzik@...il.com>, linux-kernel@...r.kernel.org,
	linux-debuggers@...r.kernel.org,
	Sentaro Onizuka <sentaro@...zon.com>
Subject: Re: [PATCH] fs: convert mount flags to enum

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.