Re: umount -l <path>, getcwd and /proc/<pid>/cwd inconsistent

[Ian Kent <raven@themaw.net>]

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