namec (was Re: [9fans] Strange date/time on some created files)

namec (was Re: [9fans] Strange date/time on some created files)

[rog]

this conversation reminds me of a little piece of
annoying behaviour under plan9.

here's a demonstration:

cpu% pwd
/usr/rog/c
cpu% > /tmp/tst
cpu% cp /bin/echo 8.out
cpu% bind 8.out /tmp/tst
cpu% /tmp/tst -z
-z
cpu% cp /bin/sed 8.out
cpu% /tmp/tst -z
tst 424799: suicide: sys: trap: fault write addr=0x24fffbde pc=0x00017e7c

the problem seems to be that attachimage() relies on sysexec()
giving it a Chan with a currently valid qid.version, but when
the last component of the path is translated by a mount
point, namec returns the qid in the mount table's Chan,
which holds a stale version number, hence the old
shared text segment incorrectly used.

i can think of several ways of fixing it, but all of them
either slow things down slightly, or increase complexity.
(for instance, one doesn't really want to do a stat when the
version returned from namec *is* current, which is almost
all the time).

Re: namec (was Re: [9fans] Strange date/time on some created files)

[Russ Cox]

> the problem seems to be that attachimage() relies on sysexec()
> giving it a Chan with a currently valid qid.version, but when
> the last component of the path is translated by a mount
> point, namec returns the qid in the mount table's Chan,
> which holds a stale version number, hence the old
> shared text segment incorrectly used.

actually, namec returns an open chan, and when the chan
is opened, the Ropen includes a qid which is dutifully copied
into c->qid.  so if you run your example from, say, ramfs, 
then it just works.

the bug is in fossil, which fails to update fid->qid.vers in an
Ropen response.  most of the time this is harmless, since the qid that is
there was computed for the immediately preceding Rwalk.
only when mount points get involved do walk and open messages
get separated significantly.

the bug is fixed on sources (/sys/src/cmd/fossil/9p.c).
new binary later.

russ

Re: [9fans] Mt. Xinu

[Bruce Ellis]

maybe a good console server - it as a bucket of serial ports.

brucee

On 2/15/06, Jim McKie <jmk@plan9.bell-labs.com> wrote:
>
> > On Fri, Feb 10, 2006 at 07:46:19PM -0800, Lyndon Nerenberg wrote:
> > ...
> > ObPlan9:  someone should port Plan 9 to the MicroVAX!
> > ...
>
> a few months ago i found a binary of the plan9 vax compiler when
> looking for something in the dump, but no source. there was one because
> the original fileserver was a vax750 with a worm drive and connections
> to gnots (terminals) were serial. there's a microvax in the storage cage
> still.
>
> --jim
>
>

namec (was Re: [9fans] Strange date/time on some created files)

[rog]

this conversation reminded me of a little piece of
annoying behaviour under plan9. [please accept my apologies if
you've seen this before - it didn't seem to get through last time]

here's a demonstration:

cpu% pwd
/usr/rog/c
cpu% > /tmp/tst
cpu% cp /bin/echo 8.out
cpu% bind 8.out /tmp/tst
cpu% /tmp/tst -z
-z
cpu% cp /bin/sed 8.out
cpu% /tmp/tst -z
tst 424799: suicide: sys: trap: fault write addr=0x24fffbde pc=0x00017e7c

the problem seems to be that attachimage() relies on sysexec()
giving it a Chan with a currently valid qid.version, but when
the last component of the path is translated by a mount
point, namec returns the qid in the mount table's Chan,
which holds a stale version number, hence the old
shared text segment incorrectly used.

i can think of several ways of fixing it, but all of them
either slow things down slightly, or increase complexity.
(for instance, one doesn't really want to do a stat when the
version returned from namec *is* current, which is almost
all the time).

Re: namec (was Re: [9fans] Strange date/time on some created files)

[rog]

oops - i got that wrong; i had expected the list
software to put a [9fans] in front of "namec". sorry.