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
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
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
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
Ian Kent <[email protected]> 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, [email protected]
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."
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