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

[Jeff Layton <jlayton@kernel.org>]

On Mon, 2026-03-02 at 18:37 +0100, Jan Kara wrote:
> On Mon 02-03-26 12:10:52, Jeff Layton wrote:
> > On Mon, 2026-03-02 at 16:26 +0100, Jan Kara wrote:
> > > On Mon 02-03-26 08:57:28, Chuck Lever wrote:
> > > > On 3/1/26 11:09 PM, NeilBrown wrote:
> > > > > On Mon, 02 Mar 2026, Chuck Lever wrote:
> > > > > > On Sun, Mar 1, 2026, at 1:09 PM, Amir Goldstein wrote:
> > > > > > > On Sun, Mar 1, 2026 at 6:21 PM Chuck Lever <cel@kernel.org> wrote:
> > > > > > > > Perhaps that description nails down too much implementation detail,
> > > > > > > > and it might be stale. A broader description is this user story:
> > > > > > > > 
> > > > > > > > "As a system administrator, I'd like to be able to unexport an NFSD
> > > > > > > 
> > > > > > > Doesn't "unexporting" involve communicating to nfsd?
> > > > > > > Meaning calling to svc_export_put() to path_put() the
> > > > > > > share root path?
> > > > > > > 
> > > > > > > > share that is being accessed by NFSv4 clients, and then unmount it,
> > > > > > > > reliably (for example, via automation). Currently the umount step
> > > > > > > > hangs if there are still outstanding delegations granted to the NFSv4
> > > > > > > > clients."
> > > > > > > 
> > > > > > > Can't svc_export_put() be the trigger for nfsd to release all resources
> > > > > > > associated with this share?
> > > > > > 
> > > > > > Currently unexport does not revoke NFSv4 state. So, that would
> > > > > > be a user-visible behavior change. I suggested that approach a
> > > > > > few months ago to linux-nfs@ and there was push-back.
> > > > > > 
> > > > > 
> > > > > Could we add a "-F" or similar flag to "exportfs -u" which implements the
> > > > > desired semantic?  i.e.  asking nfsd to release all locks and close all
> > > > > state on the filesystem.
> > > > 
> > > > That meets my needs, but should be passed by the linux-nfs@ review
> > > > committee.
> > > > 
> > > > -F could probably just use the existing "unlock filesystem" API
> > > > after it does the unexport.
> > > 
> > > If this option flies, then I guess it is the most sensible variant. If it
> > > doesn't work for some reason, then something like ->umount_begin sb
> > > callback could be twisted (may possibly need some extension) to provide
> > > the needed notification? At least in my naive understanding it was created
> > > for usecases like this...
> > > 
> > > 								Honza
> > 
> > umount_begin is a superblock op that only occurs when MNT_FORCE is set.
> > In this case though, we really want something that calls back into
> > nfsd, rather than to the fs being unmounted.
> 
> I see OK.
> 
> > You could just wire up a bunch of umount_begin() operations but that
> > seems rather nasty. Maybe you could add some sort of callback that nfsd
> > could register that runs just before umount_begin does?
> 
> Thinking about this more - Chuck was also writing about the problem of
> needing to shutdown the state only when this is the last unmount of a
> superblock but until we grab namespace_lock(), that's impossible to tell in
> a race-free manner? And how about lazy unmounts? There it would seem to be
> extra hard to determine when NFS needs to drop it's delegations since you
> need to figure out whether all file references are NFS internal only? It
> all seems like a notification from VFS isn't the right place to solve this
> issue...
> 

The issue is that traditionally, "exportfs -u" is what unexports the
filesystem and at that point you can (usually) unmount it. We'd ideally
like to have a solution that doesn't create extra steps or change this,
since there is already a lot of automation and muscle memory around
these commands.

This method mostly works with v3, since there is no long term state
(technically lockd can hold some, but that's only for file locking).
With v4 that changed and nfsd holds files open for much longer.

We can't drop all the state when fs is unexported, as it's not uncommon
for it to be reexported soon afterward, and we can't force a grace
period at that point to allow reclaim.

Unmounting seems like the natural place for this. At the point where
you're unmounting, there can be no more state and the admin's intent is
clear. Tearing down nfsd state at that point seems pretty safe.

If we can't add some sort of hook to the umount path, then I'll
understand, but it would be a nice to have for this use-case.
-- 
Jeff Layton <jlayton@kernel.org>