* namec (was Re: [9fans] Strange date/time on some created files)
@ 2006-02-12 13:58 rog
2006-02-15 8:32 ` Russ Cox
0 siblings, 1 reply; 4+ messages in thread
From: rog @ 2006-02-12 13:58 UTC (permalink / raw)
To: 9fans, 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).
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: namec (was Re: [9fans] Strange date/time on some created files)
2006-02-12 13:58 namec (was Re: [9fans] Strange date/time on some created files) rog
@ 2006-02-15 8:32 ` Russ Cox
0 siblings, 0 replies; 4+ messages in thread
From: Russ Cox @ 2006-02-15 8:32 UTC (permalink / raw)
To: 9fans
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [9fans] Mt. Xinu
@ 2006-02-15 6:29 Bruce Ellis
2006-02-15 13:04 ` namec (was Re: [9fans] Strange date/time on some created files) rog
0 siblings, 1 reply; 4+ messages in thread
From: Bruce Ellis @ 2006-02-15 6:29 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* namec (was Re: [9fans] Strange date/time on some created files)
2006-02-15 6:29 [9fans] Mt. Xinu Bruce Ellis
@ 2006-02-15 13:04 ` rog
2006-02-15 13:07 ` rog
0 siblings, 1 reply; 4+ messages in thread
From: rog @ 2006-02-15 13:04 UTC (permalink / raw)
To: 9fans
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).
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-02-15 13:07 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-02-12 13:58 namec (was Re: [9fans] Strange date/time on some created files) rog
2006-02-15 8:32 ` Russ Cox
2006-02-15 6:29 [9fans] Mt. Xinu Bruce Ellis
2006-02-15 13:04 ` namec (was Re: [9fans] Strange date/time on some created files) rog
2006-02-15 13:07 ` rog
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).