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

[Chuck Lever <cel@kernel.org>]

On 2/26/26 8:32 AM, Jan Kara wrote:
> On Thu 26-02-26 08:27:00, Chuck Lever wrote:
>> 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:
>>>> 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.
> 
> Yeah, then as Amir writes placing a mark with FS_UNMOUNT event on the
> export root path and handling the event in
> nfsd_file_fsnotify_handle_event() should do what you need?

Turns out FS_UNMOUNT doesn't do what I need.

1/3 here has a fatal flaw: the SRCU notifier does not fire until all
files on the mount are closed. The problem is that NFSD holds files
open when there is outstanding NFSv4 state. So the SRCU notifier will
never fire, on umount, to release that state.

FS_UNMOUNT notifiers have the same issue.

They fire from fsnotify_sb_delete() inside generic_shutdown_super(),
which runs inside deactivate_locked_super(), which runs when s_active
drops to 0. That requires all mounts to be freed, which requires all
NFSD files to be closed: the same problem.

For any notification approach to actually do what is needed, it needs to
fire during do_umount(), before propagate_mount_busy(). Something like:

do_umount(mnt):
    <- NEW: notify subsystems, allow them to release file refs
    retval = propagate_mount_busy(mnt, 2)   // now passes
    umount_tree(mnt, ...)

This is what Christian's "internal watches... execute blocking stuff"
would need to enable. The existing fsnotify plumbing (groups, marks,
event dispatch) provides the infrastructure, but a new notification hook
in do_umount() is required — neither fsnotify_vfsmount_delete() nor
fsnotify_sb_delete() fires early enough.

But a hook in do_umount() fires for every mount namespace teardown, not
just admin-initiated unmounts. NFSD's callback would need to filter
(e.g., only act when it's the last mount of a superblock that NFSD is
exporting).

This is why I originally went with fs_pin. Not saying the series should
go back to that, but this is the basic requirement: NFSD needs
notification of a umount request while files are still open on that
mount, so that it can revoke the NFSv4 state and close those files.


-- 
Chuck Lever