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? > 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...
