linux-kernel - Re: [PATCH] fs/namei: Remove redundant DCACHE_MANAGED_DENTRY check in __follow_mount

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] [day] [month] [year] [list]

Message-ID: <CAGudoHEjifON3TvRBtf-yrT11Ty-O0qentcGQKp4hjA42a3Bhw@mail.gmail.com>
Date: Thu, 8 Jan 2026 10:42:59 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Breno Leitao <leitao@...ian.org>, Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	jlayton@...nel.org, rostedt@...dmis.org, kernel-team@...a.com
Subject: Re: [PATCH] fs/namei: Remove redundant DCACHE_MANAGED_DENTRY check in __follow_mount_rcu

On Wed, Jan 7, 2026 at 9:52 PM Al Viro <viro@...iv.linux.org.uk> wrote:
> TBH, this (starting with READ_ONCE()) is quite pointless; documentation is
> badly needed in the area, but asserts will not replace it.
>
> Note that mount traversal *is* wrapped in mount_lock seqcount check; anything
> that used to be a mountpoint, but has ceased to be such will automatically
> trigger a full repeat of pathwalk in non-rcu mode.  What's more, the same
> check is done upon the transition from rcu to non-rcu, with the same effect
> of a mismatch.
>
> This READ_ONCE() is pointless, with or without a check in the next line
> being done the way it's done.  We are explicitly OK with the damn thing
> changing under us; the check in the beginning of __follow_mount_rcu()
> is only a shortcut for very common case, equivalent to what the loop
> below would've done if we didn't have that check there.
>

As far as I can tell it currently happens to not matter for
__follow_mount_rcu, so there is no correctness issue as is.

I do claim that basic hygiene in case of lockless code dictates stuff
gets read and acted on once if feasible, even if the code at hand
would be fine without it.

Any outsider (e.g., me) reading this diff has to pause and ponder if
it changes anything and this is trivially avoidable by passing the
found value into the routine.