Re: [PATCH v3 1/3] fs: add umount notifier chain for filesystem unmount notification

[Chuck Lever <cel@kernel.org>]

On 2/26/26 5:52 AM, Amir Goldstein wrote:
> On Thu, Feb 26, 2026 at 9:48 AM Christian Brauner <brauner@kernel.org> wrote:
>>
>> On Tue, Feb 24, 2026 at 11:39:06AM -0500, Chuck Lever wrote:
>>> From: Chuck Lever <chuck.lever@oracle.com>
>>>
>>> Kernel subsystems occasionally need notification when a filesystem
>>> is unmounted. Until now, the only mechanism available is the fs_pin
>>> infrastructure, which has limited adoption (only BSD process
>>> accounting uses it) and VFS maintainers consider it deprecated.
>>>
>>> Add an SRCU notifier chain that fires during mount teardown,
>>> following the pattern established by lease_notifier_chain in
>>> fs/locks.c. The notifier fires after processing stuck children but
>>> before fsnotify_vfsmount_delete(), at which point SB_ACTIVE is
>>> still set and the superblock remains fully accessible.
> 
> Did you see commit 74bd284537b34 ("fsnotify: Shutdown fsnotify
> before destroying sb's dcache")?
> 
> Does it make the fsnotify_sb_delete() hook an appropriate place
> for this cleanup?
> 
> We could send an FS_UNMOUNT event on sb, the same way as we send
> it on inode in fsnotify_unmount_inodes().
> 
>>
>> What I don't understand is why you need this per-mount especially
>> because you say above "when a filesystem is mounted. Could you explain
>> this in some more details, please?
>>
> 
> The confusing thing is that FS_UNMOUNT/IN_UNMOUNT are sent
> for inotify when the sb is destroyed, not when the mount is unmounted.
> 
> If we wanted we could also send FS_UNMOUNT in fsnotify_vfsmount_delete(),
> but that would be too confusing.
> 
> I think the only reason that we did not add fanotify support for FAN_UNMOUNT
> is this name confusion, but there could be other reasons which I don't
> remember.
> 
>> Also this should take namespaces into account somehow, right? As Al
>> correctly observed anything that does CLONE_NEWNS and inherits your
>> mountable will generate notifications. Like, if systemd spawns services,
>> if a container runtime start, if someone uses unshare you'll get
>> absolutely flooded with events. I'm pretty sure that is not what you
>> want and that is defo not what the VFS should do...

I agree with Al's earlier comment and have added some protection there
for the next revision of the series.


>> Another thing: These ad-hoc notifiers are horrific. So I'm pitching
>> another idea and I hope that Jan and Amir can tell me that this is
>> doable...
>>
>> Can we extend fsnotify so that it's possible for a filesystem to
>> register "internal watches" on relevant objects such as mounts and
>> superblocks and get notified and execute blocking stuff if needed.
>>
> 
> You mean like nfsd_file_fsnotify_group? ;)
> 
>> Then we don't have to add another set of custom notification mechanisms
>> but have it available in a single subsystem and uniformely available.
>>
> 
> I don't see a problem with nfsd registering for FS_UNMOUNT
> event on sb (once we add it).
> 
> As a matter of fact, I think that nfsd can already add an inode
> mark on the export root path for FS_UNMOUNT event.

There isn't much required here aside from getting a synchronous notice
that the final file system unmount is going on. I'm happy to try
whatever mechanism VFS maintainers are most comfortable with.


-- 
Chuck Lever