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

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

[Ian Kent]

Hi all,

Could someone please help me understand what's happening with, what
looks like inconsistent behavior, between getpwd and procfs readlink.

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.

For example:

[raven@raven ~]$ mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/mapper/VolGroup00-LogVol03 on /work type ext3 (rw)
/dev/mapper/VolGroup00-LogVol02 on /home type ext3 (rw)
/dev/mapper/VolGroup02-LogVol00 on /vmware type ext3 (rw)
/dev/sda2 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
shark:/export/auto on /mnt/auto type nfs (rw,addr=10.49.97.44)
[raven@raven ~]$ cd /mnt/auto
[raven@raven auto]$ pwd
/mnt/auto
[raven@raven auto]$ ps
  PID TTY          TIME CMD
 5435 pts/2    00:00:00 bash
 5543 pts/2    00:00:00 ps
[raven@raven auto]$ ls -ld /proc/5435/cwd
lrwxrwxrwx 1 raven raven 0 2008-01-07 11:57 /proc/5435/cwd -> /mnt/auto

"umount -l /mnt/auto", done elsewhere at this point.

[raven@raven auto]$ mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/mapper/VolGroup00-LogVol03 on /work type ext3 (rw)
/dev/mapper/VolGroup00-LogVol02 on /home type ext3 (rw)
/dev/mapper/VolGroup02-LogVol00 on /vmware type ext3 (rw)
/dev/sda2 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
[raven@raven auto]$ pwd
/mnt/auto
[raven@raven auto]$ ls -ld /proc/5435/cwd
lrwxrwxrwx 1 raven raven 0 2008-01-07 11:57 /proc/5435/cwd ->
[raven@raven auto]$


Ian

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

[Bauke Jan Douma]

Ian Kent wrote on 07-01-08 04:17:
> Hi all,
> 
> Could someone please help me understand what's happening with, what
> looks like inconsistent behavior, between getpwd and procfs readlink.
> 
> 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.
> 
[snip]

What does `/bin/pwd' return, when you do that instead of
plain `pwd' (after the umount)?

bjd

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

[Ian Kent]

On Mon, 2008-01-07 at 09:29 +0100, Bauke Jan Douma wrote:
> Ian Kent wrote on 07-01-08 04:17:
> > Hi all,
> > 
> > Could someone please help me understand what's happening with, what
> > looks like inconsistent behavior, between getpwd and procfs readlink.
> > 
> > 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.
> > 
> [snip]
> 
> What does `/bin/pwd' return, when you do that instead of
> plain `pwd' (after the umount)?

I did check that at one point and it returned the same as pwd.
I'll check again later, but I remember I explicitly checked that along
the way.

Ian

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

[Ian Kent]

On Mon, 2008-01-07 at 17:55 +0900, Ian Kent wrote:
> On Mon, 2008-01-07 at 09:29 +0100, Bauke Jan Douma wrote:
> > Ian Kent wrote on 07-01-08 04:17:
> > > Hi all,
> > > 
> > > Could someone please help me understand what's happening with, what
> > > looks like inconsistent behavior, between getpwd and procfs readlink.
> > > 
> > > 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.
> > > 
> > [snip]
> > 
> > What does `/bin/pwd' return, when you do that instead of
> > plain `pwd' (after the umount)?
> 
> I did check that at one point and it returned the same as pwd.
> I'll check again later, but I remember I explicitly checked that along
> the way.

Hey, I was sure I tested that.
It, in fact, returns nothing also.

Ian

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

[Andreas Schwab]

Ian Kent <raven@themaw.net> writes:

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

Builtin pwd just prints $PWD.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Ian Kent]

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