Messages in this thread | | | Subject | Re: umount -l <path>, getcwd and /proc/<pid>/cwd inconsistent | From | Ian Kent <> | Date | Wed, 09 Jan 2008 12:10:30 +0900 |
| |
On Mon, 2008-01-07 at 12:17 +0900, Ian Kent wrote: > > Basically, from a bash shell, setting working directory to a mounted > directory all is fine with "pwd" and "/proc/<pid>/cwd". Following a > "umount - l" on the mount "pwd" continues to return the expected string > but "/proc/<pid>/cwd" returns an empty string. > > What I'm really after is why this happens because sys_getcwd and > proc_pid_readlink appear to do essentially the same thing to get the > string.
I think I understand what happens here now.
Basically, following a "umount -l", anything that calls d_path from within the unlinked mount and doesn't have a d_name dentry ops method can no longer walk back up to the root to get the path.
Of course this makes perfect sense as the mount has been unlinked from the tree.
But it can also prevent processes still using the mount from successfully running through to completion to release the mount. I expect this was never the intent of the functionality but I think it should be. Especially since the VFS appears to handle this really well otherwise.
So, I'm after suggestions: Does anyone feel strongly that this case shouldn't be handled for some reason? Why? Does anyone have any suggestions about how this should be done? Does anyone have any concerns about what shouldn't be done to deal with this?
Ian
| |