9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] ramfs, lib9p
@ 2004-04-27 16:07 Martin Wyser
  2004-04-27 16:18 ` Fco.J.Ballesteros
  2004-04-27 16:32 ` rog
  0 siblings, 2 replies; 5+ messages in thread
From: Martin Wyser @ 2004-04-27 16:07 UTC (permalink / raw)
  To: 9fans

Boys, and of course Girls too:

I noticed that there are two ramfs implementations:
/sys/src/cmd/ramfs.c    seems old, because does not use lib9p
/sys/src/lib9p/ramfs.c  seems newer, because does use lib9p

Unfortunately, both have bad bugs.  I would suggest dumping the old one, 
  and in that spirit started looking at the problems with the newer.

I did
cd /tmp
mkdir ramfs
8c /sys/src/lib9p/ramfs.c
8l -o ramfs ramfs.8
./ramfs -s ramfs
mount -c /srv/ramfs /tmp/ramfs
unmount /tmp/ramfs
mount -c /srv/ramfs /tmp/ramfs   #again
ls /tmp/ramfs   #crashes nicely

So I started looking through it, and it looks like the problems are in 
lib9p.  Where to send my findings?  Discuss them here?
(I checked with sources and found that I am up-to-date).

kind regards, Martin

With some -D and acid, I got the following information:
-----
<-5- Tversion tag 65535 msize 8216 version '9P2000'
-5-> Rversion tag 65535 msize 8216 version '9P2000'
<-5- Tauth tag 3 afid 211 uname mwyser aname
-5-> Rerror tag 3 ename ./ramfs: authentication not required
<-5- Tattach tag 3 fid 211 afid -1 uname mwyser aname
-5-> Rattach tag 3 qid (0000000000000000 0 d)
<-5- Tclunk tag 3 fid 211
-5-> Rclunk tag 3
<-5- Tauth tag 3 afid 208 uname mwyser aname
-5-> Rerror tag 3 ename ./ramfs: authentication not required
<-5- Tattach tag 3 fid 208 afid -1 uname mwyser aname
-5-> Rattach tag 3 qid (0000000000000000 0 d)
<-5- Twalk tag 3 fid 208 newfid 212 nwname 0
-5-> Rwalk tag 3 nwqid 0
<-5- Tstat tag 3 fid 212
-5-> Rstat tag 3  stat 'mwyser' '\x03' 'mwyser' 'mwyser' q 
(0000000000000000 0 d) m 020000000777 at 1083085032 mt 1083085032 l 0 t 
0 d 0
<-5- Tclunk tag 3 fid 212
-5-> Rclunk tag 3
panic: D2B called on non-block 18394 (double-free?) (magic 00000000)
ramfs 122: suicide: sys: trap: fault read addr=0x0 pc=0x00004b63

acid: stk()
abort()+0x0 /sys/src/libc/9sys/abort.c:6
ppanic(p=0x17d5c,fmt=0x17914)+0x152 /sys/src/libc/port/malloc.c:158
D2B(v=0x18394,p=0x17d5c)+0x38 /sys/src/libc/port/pool.c:944
poolfreel(v=0x18394,p=0x17d5c)+0x20 /sys/src/libc/port/pool.c:1065
poolfree(p=0x17d5c,v=0x18394)+0x41 /sys/src/libc/port/pool.c:1175
free(v=0x1839c)+0x23 /sys/src/libc/port/malloc.c:228
fsdestroyfile(f=0x18330)+0x29 /usr/mwyser/ramfs/ramfs.c:111
closefile(f=0x18330)+0x23 /sys/src/lib9p/file.c:75
closefid(f=0x1d808)+0x5f /sys/src/lib9p/fid.c:71
closereq(r=0x1d428)+0x77 /sys/src/lib9p/req.c:79
respond(error=0x0,r=0x1d428)+0x31f /sys/src/lib9p/srv.c:803
sclunk(srv=0x1306c,r=0x1d428)+0x51 /sys/src/lib9p/srv.c:548
srv(srv=0x1306c)+0x1be /sys/src/lib9p/srv.c:702
_post2(v=0x1306c)+0x4f /sys/src/lib9p/_post.c:41
postmountsrv(s=0x1306c,name=0x7fffeff6,mtpt=0x0,flag=0x4)+0x5e 
/sys/src/lib9p/post.c:19
main(argv=0x7fffefe0,argc=0x0)+0x105 /usr/mwyser/ramfs/ramfs.c:162
_main+0x31 /sys/src/libc/386/main9.s:16
acid:
------


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] ramfs, lib9p
  2004-04-27 16:07 [9fans] ramfs, lib9p Martin Wyser
@ 2004-04-27 16:18 ` Fco.J.Ballesteros
  2004-04-27 16:32 ` rog
  1 sibling, 0 replies; 5+ messages in thread
From: Fco.J.Ballesteros @ 2004-04-27 16:18 UTC (permalink / raw)
  To: 9fans

> I noticed that there are two ramfs implementations:
> /sys/src/cmd/ramfs.c    seems old, because does not use lib9p
> /sys/src/lib9p/ramfs.c  seems newer, because does use lib9p

Surprisingly, the one I'm using is the old one, as reported by src.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] ramfs, lib9p
  2004-04-27 16:07 [9fans] ramfs, lib9p 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
  1 sibling, 2 replies; 5+ messages in thread
From: rog @ 2004-04-27 16:32 UTC (permalink / raw)
  To: 9fans

> /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?



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] ramfs, lib9p
  2004-04-27 16:32 ` rog
@ 2004-04-27 18:18   ` Russ Cox
  2004-04-28  9:33   ` Martin Wyser
  1 sibling, 0 replies; 5+ messages in thread
From: Russ Cox @ 2004-04-27 18:18 UTC (permalink / raw)
  To: 9fans

/sys/src/lib9p/ramfs.c is intended as a simple example
of using lib9p.  

/sys/src/cmd/ramfs.c is intended as a simple example
of not using lib9p.

neither will go away any time soon.  
there was a time when i replaced the non-lib9p
with the lib9p version, but when we switched
protocols, it was helpful to be able to have a
toy server to experiment with before lib9p had
been fully converted, hence the old one was
revived.

feel free to fix or identify bugs in both.
if you fix bugs you can submit the fixes
via patch(1).  if you just identify them,
you can mail 9trouble and we'll fix them.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] ramfs, lib9p
  2004-04-27 16:32 ` rog
  2004-04-27 18:18   ` Russ Cox
@ 2004-04-28  9:33   ` Martin Wyser
  1 sibling, 0 replies; 5+ messages in thread
From: Martin Wyser @ 2004-04-28  9:33 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2004-04-28  9:33 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-27 16:07 [9fans] ramfs, lib9p 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 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).