9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Martin Wyser <martin.wyser@inf.ethz.ch>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ramfs, lib9p
Date: Wed, 28 Apr 2004 09:33:49 +0000	[thread overview]
Message-ID: <408f770d$1@pfaff2.ethz.ch> (raw)
In-Reply-To: <99c511594f4894ba7d456adfac2c3862@vitanuova.com>

rog@vitanuova.com wrote:
>>/sys/src/lib9p/ramfs.c  seems newer, because does use lib9p
> 
> 
> newer, but not much used.
> 
> i'd not be surprised if the newer version was written just to test
> lib9p and wasn't as fully featured as /sys/src/cmd/ramfs.c (for
> instance, the lib9p version doesn't deal with exclusive-use files, as
> far as i can see).
> 
> what are the "bad bugs" in the older one?
> 

I do
ramfs -s -D
aux/nfsserver -f /srv/ramfs -c /lib/ndb/nfs.martin
aux/portmapper
Then I mount on my linux box at /mnt, then ls /mnt, which hangs, but
triggers the suicide message below (ramfs protocol trace at end).

It comes out that ropen in ramfs.c (the one in cmd/) dereferences a null 
  pointer at ramfs.c:368:
367	r=f->ram;	//f->ram is nil
368	if(r->busy)	//r is nil too
The null pointer is set up by newfid() at ramfs:c:738, the calls to 
newfid() and ropen() are made at ramfs.c:787.

It seems to me that the deadly Topen sent by nfsserver could be a bug 
(or at least protocol nonsense) too, but even if so, ramfs is supposed 
to give an Rerror, rather than just crash.
There may be easier ways to crash ramfs than using nfsserver, but as 
mentioned, I did not invest much time, because I want to concentrate on 
the 'newer' ramfs.  After all, using lib9p looks like the future, but it 
could use some excercising to grow strong, sort of.

regards, Martin

ramfs 106:<-Tversion tag 65535 msize 8216 version '9P2000'
ramfs 106:->Rversion tag 65535 msize 8216 version '9P2000'
ramfs 106:<-Tattach tag 1 fid 0 afid -1 uname none aname
ramfs 106:->Rattach tag 1 qid (0000000000000000 0 d)
ramfs 106:<-Tstat tag 2 fid 0
ramfs 106:->Rstat tag 2  stat '.' 'mwyser' 'mwyser' 'mwyser' q 
(0000000000000000 0 d) m 020000000775 at 1083164331 mt 1083164331 l 0 t 
65535 d -256
ramfs 106:<-Tstat tag 3 fid 0
ramfs 106:->Rstat tag 3  stat '.' 'mwyser' 'mwyser' 'mwyser' q 
(0000000000000000 0 d) m 020000000775 at 1083164331 mt 1083164331 l 0 t 
65535 d -256
ramfs 106:<-Twalk tag 4 fid 0 newfid 1 nwname 0
ramfs 106:->Rwalk tag 4 nwqid 0
ramfs 106:<-Topen tag 5 fid 1 mode 0
ramfs 106: suicide: sys: trap: fault read addr=0x0 pc=0x000018f4


      parent reply	other threads:[~2004-04-28  9:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-27 16:07 Martin Wyser
2004-04-27 16:18 ` Fco.J.Ballesteros
2004-04-27 16:32 ` rog
2004-04-27 18:18   ` Russ Cox
2004-04-28  9:33   ` Martin Wyser [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='408f770d$1@pfaff2.ethz.ch' \
    --to=martin.wyser@inf.ethz.ch \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).