kern/98064: Crash with FIFOs (named pipes) and truncate()

[Bruce Evans]

The following reply was made to PR kern/98064; it has been noted by GNATS.

From: Bruce Evans <bde at zeta.org.au>
To: Maxim Konovalov <maxim at macomnet.ru>
Cc: freebsd-gnats-submit at FreeBSD.org
Subject: Re: kern/98064: Crash with FIFOs (named pipes) and truncate()
Date: Wed, 31 May 2006 23:06:15 +1000 (EST)

 On Wed, 31 May 2006, Maxim Konovalov wrote:
 
 > [...]
 >> 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?
 
 fip is always null for non-open fifos, and truncate(2) doesn't open
 the file.
 
 Change the printing to print just ", fifo" or ", closed fifo" in the
 fip == NULL case.
 
 I would have expected RELENG_4 to panic here too.  Maybe the vnop plumbing
 is broken in RELENG_4, resulting in fifo_print() not being called.
 
 Bruce