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 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.

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?

That would be preferable from a UI standpoint than dealing with a new
exportfs option, IMO. MNT_FORCE could then (in theory) properly allow
for state teardown in nfsd that way, which seems rather natural.
-- 
Jeff Layton <jlayton@kernel.org>