Bug 5615

Summary:	odd cwd behavior
Product:	File System	Reporter:	Eric Van Hensbergen (ericvh)
Component:	v9fs	Assignee:	Eric Van Hensbergen (ericvh)
Status:	CLOSED CODE_FIX
Severity:	high
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.16-rc4	Subsystem:
Regression:	---	Bisected commit-id:

Description Eric Van Hensbergen 2005-11-16 07:58:29 UTC

(From Jim Garlick)
I'm playing with v9fs a bit and found some odd behavior with getcwd.
(Nice job getting v9fs into the 2.6.14 - the downside is people will find it
and use it :-)

Here is my setup:

* Fedora Core 3 box running 2.6.9-1.667 kernel, runs u9fs (grabbed from
v9fs project cvs today) via xinetd.

* Fedora Core 4 box running 2.6.14-1.1637_FC4 kernel mounts the first box's
filesystem with "mount -t 9P <ip of first box> /w".  u9fs starts up on
the first box running as nobody.

Now if I cd into a subdirectory of the mounted 9P file system - not /w but
something under that - and run /bin/pwd, it works.  If I do an ls, then
/bin/pwd again, it doesn't and an strace shows getcwd returning ENOENT.
If I cd to .. and then back again, /bin/pwd works.  Another ls, and then
/bin/pwd gets ENOENT.

Comment 1 Eric Van Hensbergen 2005-11-16 07:59:07 UTC

Here's a funny twist:

bash-2.05b# cd /mnt/9
bash-2.05b# cd /
bash-2.05b# cd /mnt/9/tmp
bash-2.05b# pwd
/mnt/9/tmp
bash-2.05b# ls
u9fs.log
bash-2.05b# pwd
/mnt/9/tmp
bash-2.05b# ls
u9fs.log
bash-2.05b# pwd
/mnt/9/tmp
bash-2.05b# ls
u9fs.log
bash-2.05b# pwd
/mnt/9/tmp
bash-2.05b# /bin/pwd
/bin/pwd: cannot get current directory: No such file or directory

With debug on:
bash-2.05b# /bin/pwd
/mnt/9/tmp
bash-2.05b# ls
-- v9fs_fid_get_created (123):  dentry: tmp (c00000000745ae08)
-- v9fs_fid_get_created (123): return 0000000000000000
-- v9fs_fid_lookup (123):  dentry: tmp (c00000000745ae08)
-- v9fs_t_walk (123): fid 1 newfid 2 wname '<NULL>'
-- v9fs_t_open (123): fid 2 mode 0
-- v9fs_fid_lookup (123):  dentry: tmp (c00000000745ae08)
-- v9fs_t_stat (123): fid 1
-- v9fs_t_read (123): fid 2 offset 0x0 count 0x2310
-- v9fs_t_read (123): fid 2 offset 0x9b count 0x2310
-- v9fs_t_read (123): fid 2 offset 0x9b count 0x2310
-- v9fs_t_clunk (123): fid 2
u9fs.log
bash-2.05b# /bin/pwd
/bin/pwd: cannot get current directory: No such file or directory

(note the lack of any v9fs debug on the pwd's) -- it's definitely
something screwy with the dcache.  I'll have to instrument with some
more debug.  Potentially this is the motivation I need to rewrite the
fid management stuff (which is behind the aggressive dcache
invalidation).

Comment 2 Eric Van Hensbergen 2006-02-19 14:48:39 UTC

Upping priority as it made Andrew's issues list. Will try and resolve this in
the next few days.

Comment 3 Eric Van Hensbergen 2006-02-20 18:39:08 UTC

I'm writing up implementation notes for the fix in swik:
http://swik.net/FID-mapping-rework

I think I have a workable scenerio but it'll take me a few more days to
implement and try it out.

Comment 4 Eric Van Hensbergen 2006-02-25 16:24:02 UTC

fixed in v9fs-devel.git tree on kernel.org