On Thu, Aug 29, 2019 at 09:12:49PM +0300, Alex Lyakas wrote: > Would moving this code into the "unlock_filesystem" infrastructure be > acceptable? Since the "share_id" approach is very custom for our > usage, what criteria would you suggest for selecting the openowners to > be "forgotten"? Have you looked at what unlock_filesystem()? It's just translating the given path to a superblock, then matching that against inodes in nlmsvc_match_sb(). It's a little more complicated for nfs4_files since they don't have a pointer to the inode. (Maybe it should.) You can see how I get around this in e.g. fs/nfsd/nfs4state.c:nfs4_show_lock(). A superblock isn't the same thing as an export, thanks to bind mounts and subdirectory exports. But if the goal is to be able to unmount, then a superblock is probably what you want. --b.
