what's going on here? cpu% bind /net /net.alt cpu% cd /net.alt/icmp cpu% ls -l --rw-rw-rw- I 0 network bootes 0 Jun 28 12:36 clone --r--r--r-- I 0 network bootes 0 Jun 28 12:36 stats cpu% mkdir /tmp/empty cpu% bind /tmp/empty /net cpu% cd /net.alt/icmp # doesn't work! Can't cd /net.alt/icmp: '/net.alt/icmp' file does not exist cpu% cd /net.alt cpu% cd icmp # ... but this does work. cpu% ls -l --rw-rw-rw- I 0 network bootes 0 Jun 28 12:36 clone --r--r--r-- I 0 network bootes 0 Jun 28 12:36 stats cpu%
what's going on here? the bind of an empty directory onto /net seems to disrupt the mount table somehow. i can't think of an existing feature of the namespace implementation that would explain this behaviour. is something ignoring the device number, maybe? does anyone else get the same behaviour? % bind /net /net.alt % mkdir /tmp/empty % bind /tmp/empty /net % cd /net.alt/tcp Can't cd /net.alt/tcp: '/net.alt/tcp' file does not exist cpu% ls -l /net.alt/tcp ls: /net.alt/tcp: '/net.alt/tcp' file does not exist % cd /net.alt % cd tcp % ls -l --rw-rw-rw- I 0 network bootes 0 Jun 28 12:36 clone --r--r--r-- I 0 network bootes 0 Jun 28 12:36 stats % [sorry if this post appears a few times in different forms; i'm trying to get past what i assume is a garbage detector, so i'm assuming that more text to transcript might make it think it's a legit post, but you never know; i'll just keep adding random text until its likes it. or maybe it's something else entirely; we'll see. sorry for this garbage]
> does anyone else get the same behaviour?
>
> % bind /net /net.alt
> % mkdir /tmp/empty
> % bind /tmp/empty /net
> % cd /net.alt/tcp
> Can't cd /net.alt/tcp: '/net.alt/tcp' file does not exist
> cpu% ls -l /net.alt/tcp
> ls: /net.alt/tcp: '/net.alt/tcp' file does not exist
> % cd /net.alt
> % cd tcp
> % ls -l
> --rw-rw-rw- I 0 network bootes 0 Jun 28 12:36 clone
> --r--r--r-- I 0 network bootes 0 Jun 28 12:36 stats
> %
i tried it with ramfs -D for a clue.
cpu% bind /net /net.alt
cpu% ramfs -D -m /tmp/empty
ramfs 229917:<-Tversion tag 65535 msize 8216 version '9P2000'
ramfs 229917:->Rversion tag 65535 msize 8216 version '9P2000'
ramfs 229917:<-Tattach tag 6 fid 1180 afid -1 uname fst aname
ramfs 229917:->Rattach tag 6 qid (0000000000000000 0 d)
cpu% bind /tmp/empty /net
cpu% cd /net.alt/tcp
ramfs 229917:<-Twalk tag 6 fid 1180 newfid 583 nwname 1 0:tcp
ramfs 229917:->Rerror tag 6 ename file does not exist
Can't cd /net.alt/tcp: '/net.alt/tcp' file does not exist
cpu% cd /net.alt
cpu% cd tcp
cpu% ls -l
d-r-xr-xr-x I 0 bootes bootes 0 Nov 10 2004 0
...
that made me wonder of /net is bound before /net.alt; so i forced after:
cpu% bind -a /net /net.alt
cpu% ramfs -D -m /tmp/empty
ramfs 229992:<-Tversion tag 65535 msize 8216 version '9P2000'
ramfs 229992:->Rversion tag 65535 msize 8216 version '9P2000'
ramfs 229992:<-Tattach tag 16 fid 1153 afid -1 uname fst aname
ramfs 229992:->Rattach tag 16 qid (0000000000000000 0 d)
cpu% bind /tmp/empty /net
cpu% cd /net.alt/tcp
cpu% ls -l
d-r-xr-xr-x I 0 bootes bootes 0 Nov 10 2004 0
...
> what's going on here? the bind of an empty directory onto
> /net seems to disrupt the mount table somehow.
> i can't think of an existing feature of the namespace
> implementation that would explain this behaviour.
> is something ignoring the device number, maybe?
>
> does anyone else get the same behaviour?
>
> % bind /net /net.alt
> % mkdir /tmp/empty
> % bind /tmp/empty /net
> % cd /net.alt/tcp
> Can't cd /net.alt/tcp: '/net.alt/tcp' file does not exist
> cpu% ls -l /net.alt/tcp
> ls: /net.alt/tcp: '/net.alt/tcp' file does not exist
> % cd /net.alt
> % cd tcp
> % ls -l
> --rw-rw-rw- I 0 network bootes 0 Jun 28 12:36 clone
> --r--r--r-- I 0 network bootes 0 Jun 28 12:36 stats
> %
It has nothing to do with device numbers, since you can
produce the same situation with directories on a single
file server:
cpu% for(i in d1 d2 d3 d4) mkdir $i && echo >$i/this_is_$i
cpu% bind d2 d3
cpu% bind d1 d2
cpu% ls d1
d1/this_is_d1
cpu% ls d2
d2/this_is_d1
cpu% ls d3
d3/this_is_d2
cpu% ls d3/this_is_d2
ls: d3/this_is_d2: 'd3/this_is_d2' file does not exist
cpu% ls d3/this_is_d1
d3/this_is_d1
cpu%
The name space is a mapping from old files to new files.
After "bind d2 d3" and "bind d1 d2", the name space
looks like
d3 -> d2
d2 -> d1
Only one name space rule is used, so d3 translates to d2,
even though d2 translates to d1. That is, the rules are not
applied repeatedly or recursively. And in the example above,
opening d3 for read (as in "ls d3") does behave correctly,
but evaluating the path "d3/this_is_d2" apparently translates
d3 repeatedly, getting d1 instead of d2. That's the problem.
In fact, path evaluation applies the rules exactly twice:
cpu% bind d3 d4
cpu% bind d2 d3
cpu% bind d1 d2
# Now the name space looks like:
#
# d4 -> d3
# d3 -> d2
# d2 -> d1
cpu% ls d1
d1/this_is_d1
cpu% ls d2
d2/this_is_d1
cpu% ls d3
d3/this_is_d2
cpu% ls d4
d4/this_is_d3
cpu% ls d4/this_is_d3
ls: d4/this_is_d3: 'd4/this_is_d3' file does not exist
cpu% ls d4/this_is_d2
d4/this_is_d2
cpu% ls d4/this_is_d1
ls: d4/this_is_d1: 'd4/this_is_d1' file does not exist
cpu%
If path evaluation applied the rules three or more times then
the "ls d4/this_is_d1" would have succeded just as
"ls d3/this_is_d1" did in the first example.
Now it's easy to guess what is going on.
In the kernel, the domount and findmount functions translate
an active fid (a Chan) according to the current name space.
The behavior you have found suggests that somewhere
during path name evaluation (namec), domount is is
being called twice on some Chan instead of just once.
Sure enough, the invariant mentioned at the top of the
loop in namec:
An invariant is that each time through the loop,
c is on the undomount side of the mount point
is not true in the case where a mount point was encountered
in the resulting walk qids:
if(!nomount)
for(i=0; i<wq->nqid && i<ntry-1; i++)
if(findmount(&nc, &nmh, type, dev, wq->qid[i]))
break;
If this succeeds, then next time around the loop nc (which becomes c)
is on the domount side, not the undomount side. So the actual
invariant is a little more complex.
I've fixed the bug and submitted a patch.
Thanks for the report.
Russ