kern/98064: Crash with FIFOs (named pipes) and truncate()
Maxim Konovalov
maxim at macomnet.ru
Tue May 30 14:20:20 PDT 2006
The following reply was made to PR kern/98064; it has been noted by GNATS.
From: Maxim Konovalov <maxim at macomnet.ru>
To: Bruce Evans <bde at zeta.org.au>
Cc: bug-followup at freebsd.org
Subject: Re: kern/98064: Crash with FIFOs (named pipes) and truncate()
Date: Wed, 31 May 2006 01:11:51 +0400 (MSD)
[...]
> > #12 0xc047cf95 in fifo_printinfo (vp=0x0)
> > at /usr/src/sys/fs/fifofs/fifo_vnops.c:448
> > #13 0xc057249c in ufs_print (ap=0x0) at
> > #/usr/src/sys/ufs/ufs/ufs_vnops.c:1965
> > #14 0xc05d1c70 in VOP_PRINT_APV (vop=0x0, a=0xd565f7cc) at vnode_if.c:1899
> > #15 0xc050cafa in vn_printf (vp=0xc2c6c514, fmt=0xc05e2816 "%s\n")
> > at vnode_if.h:971
> > #16 0xc0502a4e in vop_nostrategy (ap=0xd565f8a8)
> > at /usr/src/sys/kern/vfs_default.c:195
>
> It has paniced in the debugging code in vop_nostrategy(). That code
> is apparently broken. vop_nostrategy() starts with a printf() that
> works. It then calls vprint() which panics. ap=0x0 in ufs_print and
> vp=0x0 in fifo_printinfo() seem to have been corrupted between printing
> some info about the fifo and panicing. Instead of panicing, vprint()
> is supposed to return. Then vop_nostrategy() is supposed to do nothing
> except fail the i/o.
It appears this stack trace is not correct. Actially it panics at
fifo_printinfo() when tries to dereference vp->v_fifoinfo. I added a
simple check (unneeded in normal situation I believe) and as expected
panic moved to VOP_STRATEGY assert.
--- fifo_vnops.c 15 Mar 2006 10:15:35 -0000 1.134
+++ fifo_vnops.c 30 May 2006 20:09:26 -0000
@@ -449,4 +449,5 @@ fifo_printinfo(vp)
- printf(", fifo with %ld readers and %ld writers",
- fip->fi_readers, fip->fi_writers);
+ if (fip != NULL)
+ printf(", fifo with %ld readers and %ld writers",
+ fip->fi_readers, fip->fi_writers);
return (0);
My traces show namei(&nd) in kern_truncate() returns nd with
ni_vp->v_fifoinfo = 0x0, ni_vp->v_type = VFIFO. That is why kernel
panics in fifo_printinfo() later. But how can it happen?
For the record: for non-INVARIANT kernel with the patch above a test
case gave:
$ ls -l afifo
prw-r--r-- 1 maxim maxim 16000 31 ÍÁÊ 01:08 afifo
as you predicted :-)
--
Maxim Konovalov
More information about the freebsd-bugs
mailing list