linux-kernel - Re: Why do very few filesystems have umount helpers

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: <20240729-abwesend-absondern-e90f3209e666@brauner>
Date: Mon, 29 Jul 2024 11:50:47 +0200
From: Christian Brauner <brauner@...nel.org>
To: Steve French <smfrench@...il.com>
Cc: linux-fsdevel <linux-fsdevel@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>, CIFS <linux-cifs@...r.kernel.org>
Subject: Re: Why do very few filesystems have umount helpers

On Sun, Jul 28, 2024 at 02:09:14PM GMT, Steve French wrote:
> I noticed that nfs has a umount helper (/sbin/umount.nfs) as does hfs
> (as does /sbin/umount.udisks2).  Any ideas why those are the only
> three filesystems have them but other fs don't?

Helpers such as mount.* or umount.* are used by util-linux. They're not
supposed to be directly used (usually).

For example, umount.udisks talks to the udisks daemon which keeps state
on the block devices it manages and it also cleans up things that were
created (directories etc.) at mount time. Such mounts are usually marked
e.g., via helper=udisks to instruct util-linux to call umount.udisks

Similar things probably apply to the others.

> Since umount does not notify the filesystem on unmount until
> references are closed (unless you do "umount --force") and therefore
> the filesystem is only notified at kill_sb time, an easier approach to
> fixing some of the problems where resources are kept around too long
> (e.g. cached handles or directory entries etc. or references on the
> mount are held) may be to add a mount helper which notifies the fs
> (e.g. via fs specific ioctl) when umount has begun.   That may be an
> easier solution that adding a VFS call to notify the fs when umount
> begins.   As you can see from fs/namespace.c there is no mount
> notification normally (only on "force" unmounts)

The first step should be to identify what exactly keeps your mount busy
in generic/044 and generic/043. If you don't know what the cause of this
is no notification from VFS will help you. My guess is that this ends up
being fixable in cifs.