On Thu, Apr 13, 2023 at 10:34 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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? > Speaking in the context of the original reproducer: This does work if you "umount -l /A" - the underlying "/A" mount, but not if you do "umount -l /A/B" (both have lost their access on the server). The problem with this is IMO, it is not very intuitive to lazy unmount the root of a whole tree like that. Also, the customer's case was autofs, and I don't think autofs does this, it tries to umount the children first and gets stuck there in this scenario. But overall yes it does make sense, IMO. > > 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... > > > 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... >
