stable/10 panic

[John Baldwin]

On Thursday, May 08, 2014 10:30:53 pm hiren panchasara wrote:
> [trimming a lot of things]
> 
> On Thu, May 8, 2014 at 9:19 AM, John Baldwin <jhb at freebsd.org> wrote:
> > On Thursday, May 08, 2014 12:39:20 am hiren panchasara wrote:
> >> On Wed, May 7, 2014 at 11:31 AM, John Baldwin <jhb at freebsd.org> wrote:
> >> >>  1639. /*
> >> >>  1640. * shutdown the pipe
> >> >>  1641. */
> >> >>  1642. static void
> >> >>  1643. pipeclose(cpipe)
> >> >>  1644. struct pipe *cpipe;
> >> >>  1645. {
> >> >>  1646. struct pipepair *pp;
> >> >>  1647. struct pipe *ppipe;
> >> >>  1648.
> >> >>  1649. KASSERT(cpipe != NULL, ("pipeclose: cpipe == NULL"));
> >> >>  1650.
> >> >>  1651. PIPE_LOCK(cpipe);
> >> >>  1652. pipelock(cpipe, 0);
> >> >>  1653. pp = cpipe->pipe_pair;
> >> >>  1654.
> >> >>  1655. pipeselwakeup(cpipe);
> >> >>
> >> >> pipeclose() gets called from pipe_dtor()
> >> >
> >> > Eh, so it seems like pipeclose() has been called twice on the same pipe which
> >> > should never happen.
> >>
> >> How did you get to that conclusion?
> >
> > The pipe's state (cpipe->pipe_present) is set to 3 (PIPE_FINALIZED) which only
> > happens at bottom of pipeclose(cpipe).  However, in your panic, you are dying
> > at the start of pipeclose() when cpipe's state should be the initial state
> > still.  That is also consistent with the panic as the knlist for the pipe has
> > already been destroyed (which happens later in pipeclose()) and that is what
> > zero's the lock fields in knlist causing the actual fault in knote().
> >
> 
> Makes sense.
> >
> > Eh, kgdb should be deterministic given a specific kernel and core file.
> > That is to say, above 'f 11', 'p *dpipe' did something, but here it
> > did not.  Are you running kgdb on the same core or a different one?
> >
> 
> Just to end the confusion:
> http://people.freebsd.org/~hiren/pipeclose_panic_stable10.txt

Bizarre.

> >> (kgdb) p *fip
> >> $2 = {fi_pipe = 0xffffffff80c96b7e, fi_readers = -2129533840,
> >> fi_writers = -8782327094120}
> >
> > The readers/writers counts here are garbage.  I probably wouldn't trust
> > the fi_pipe value either.  Would be nice to know if the various pointers
> > line up.  Also, I would expect a FIFO to have the 'NAMED' flag set and
> > thus for pipe_peer to be a different pipe (not itself), but I believe that
> > was not true from the earlier posts.
> 
> My reading of code says named pipe doesn't have different pipe for pipe_peer?
> 
> sys/kern/sys_pipe.c
> 
> #define PIPE_PEER(pipe) \
>              (((pipe)->pipe_state & PIPE_NAMED) ? (pipe) : ((pipe)->pipe_peer))

Bah, I had this backwards.

-- 
John Baldwin