Hi Bruce, On Fri, Aug 30, 2019 at 10:54 PM J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > 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. Thanks for your suggestion.The superblock approach works very well for us. Initial patch is on its way. Thanks, Alex. > > --b.
