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? > > 2/ disallow ->lookup operations: a umount is about removing an existing > > mount, so the dentries had better already be there. > > That changes the semantics; as it is, you need exec permissions on the > entire path... > Yep. But, I think it makes some sense to do so in the context of a umount. Mostly, umount is done by a privileged user anyway so avoiding permission checks isn't too great a stretch, IMO. > > Is this a terrible idea? Are there potentially problems with > > containerized setups if we were to do something like this? Are there > > better ways to solve this problem (and others like it)? Maybe this would > > be best done with a new UMOUNT_CACHED flag for umount2()? > > We already have lazy umount. And what will you do to symlinks you run > into along the way? They *are* traversed; requiring the caller to > canonicalize them will only shift the problem to userland... 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? -- Jeff Layton <jlayton@xxxxxxxxxx>
