linux-kernel - Re: [PATCH v4] fs/namespace: defer RCU sync for MNT

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: <20250420055406.GS2023217@ZenIV>
Date: Sun, 20 Apr 2025 06:54:06 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Eric Chanudet <echanude@...hat.com>
Cc: Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Clark Williams <clrkwllms@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>, Ian Kent <ikent@...hat.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-rt-devel@...ts.linux.dev,
	Alexander Larsson <alexl@...hat.com>,
	Lucas Karpinski <lkarpins@...hat.com>
Subject: Re: [PATCH v4] fs/namespace: defer RCU sync for MNT_DETACH umount

On Tue, Apr 08, 2025 at 04:58:34PM -0400, Eric Chanudet wrote:
> Defer releasing the detached file-system when calling namespace_unlock()
> during a lazy umount to return faster.
> 
> When requesting MNT_DETACH, the caller does not expect the file-system
> to be shut down upon returning from the syscall.

Not quite.  Sure, there might be another process pinning a filesystem;
in that case umount -l simply removes it from mount tree, drops the
reference and goes away.  However, we need to worry about the following
case:
	umount -l has succeeded
	<several minutes later>
	shutdown -r now
	<apparently clean shutdown, with all processes killed just fine>
	<reboot>
	WTF do we have a bunch of dirty local filesystems?  Where has the data gone?

Think what happens if you have e.g. a subtree with several local filesystems
mounted in it, along with an NFS on a slow server.  Or a filesystem with
shitloads of dirty data in cache, for that matter.

Your async helper is busy in the middle of shutting a filesystem down, with
several more still in the list of mounts to drop.  With no indication for anyone
and anything that something's going on.

umount -l MAY leave filesystem still active; you can't e.g. do it and pull
a USB stick out as soon as it finishes, etc.  After all, somebody might've
opened a file on it just as you called umount(2); that's expected behaviour.
It's not fully async, though - having unobservable fs shutdown going on
with no way to tell that it's not over yet is not a good thing.

Cost of synchronize_rcu_expedited() is an issue, all right, and it does
feel like an excessively blunt tool, but that's a separate story.  Your
test does not measure that, though - you have fs shutdown mixed with
the cost of synchronize_rcu_expedited(), with no way to tell how much
does each of those cost.

Could you do mount -t tmpfs tmpfs mnt; sleep 60 > mnt/foo &
followed by umount -l mnt to see where the costs are?