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

["Chuck Lever" <cel@kernel.org>]

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.


>> The discussion here has added some interesting corner cases: NFSD
>> can export bind mounts (portions of a local physical file system);
>> unprivileged users can create and umount file systems using "share".
>
> The basic question is whether nfsd is exporting a mount, a filesystem
> or something in between (i.e. a subtree of a filesystem).
>
> AFAIK, the current implementation is that nfsd is actually exporting
> one specific mount, so changing the properties of this mount
> (e.g. readonly) would affect the exported share.

AIUI NFSD can export starting at any arbitrary directory
that appears in the mount namespace. It does not have to
start at the local file system's root directory. But even
so, outstanding NFSv4 delegations on a narrow portion of
a mounted file system will still pin that mount.

-- 
Chuck Lever