On Fri, Apr 14, 2023 at 06:01:59AM -0400, Jeff Layton wrote: > On Fri, 2023-04-14 at 03:32 +0100, Al Viro wrote: > > On Thu, Apr 13, 2023 at 06:00:42PM -0400, Jeff Layton wrote: > > > > > It describes a situation where there are nested NFS mounts on a client, > > > and one of the intermediate mounts ends up being unexported from the > > > server. In a situation like this, we end up being unable to pathwalk > > > down to the child mount of these unreachable dentries and can't unmount > > > anything, even as root. > > > > So umount -l the stuck sucker. What's the problem with that? > > > > You mean lazy umount the parent that is stuck? What happens to the child > mount in that case? Is it also eventually cleaned up? Yes. Lazy umount takes out the contributions to refcount due to being present in mount tree; as soon as other references go away (opened files, current directories, in-progress syscalls on files in there) struct mount instance releases the active reference to filesystem instance (struct super_block) and goes away. Once all active references to filesystem instance are gone, it gets shut down. > Yeah, I hadn't considered symlinks here. Still, if we have a cached > symlink dentry, wouldn't we also already have the symlink target in > cache too? Or is that not guaranteed? Not at all. What's more, why would we have that symlink dentry cached in the first place? If you suddenly impose that kind of restrictions on umount(2), you are pretty much guaranteed to break userland... Symlink dentries are rarely pinned, BTW - they may very well be cached if we hit them often enough, but outside of the things like lchown()/lstat() or pathname resolution in progress that is currently traversing that symlink... refcount is going to be zero.
