Re: [PATCH v2 4/6] fs: invoke group_pin_kill() during mount teardown

[Al Viro <viro@zeniv.linux.org.uk>]

On Sat, Jan 10, 2026 at 03:07:38PM -0500, Chuck Lever wrote:

> 4. The result is that if a share is unexported while NFSv4 clients still
> have that share mounted, open/lock/delegation state remains in place,
> and the underlying files remain open on the NFS server. That prevents
> the shared file system from being unmounted (which is sometimes the very
> next step after unexport). As long as the NFS client maintains its lease
> (perhaps because it has other shares mounted on that server), those
> files remain open.
> 
> The workaround is that the server administrator has to use NFSD's
> "unlock file system" UI first to revoke the state IDs and close the
> files. Then the file system can be unmounted cleanly.
> 
> 
> Help me understand what you mean by write count? Currently, IIUC, any
> outstanding writes are flushed when each of the files that backs a
> stateid is closed.

File opened for write carries has write access granted at open time and
keeps it until the final fput().  Try this:

root@cannonball:/tmp# mkdir /tmp/blah
root@cannonball:/tmp# mount -t tmpfs none /tmp/blah/
root@cannonball:/tmp# exec 42>/tmp/blah/a
root@cannonball:/tmp# mount -o remount,ro /tmp/blah/
mount: /tmp/blah: mount point is busy.
       dmesg(1) may have more information after failed mount system call.
root@cannonball:/tmp# exec 42>&-
root@cannonball:/tmp# mount -o remount,ro /tmp/blah/
root@cannonball:/tmp# ls /tmp/blah/a 
/tmp/blah/a
root@cannonball:/tmp# umount /tmp/blah 
root@cannonball:/tmp#

You don't need to be in the middle of write(2); just having a file opened for
write prevents r/o remount.

Do you want to be able to
	* umount without an unexport?
	* remount read-only without an unexport?