stable/10 panic

[hiren panchasara]

[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
>
>> (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))

cheers,
Hiren