On Mon, Feb 21, 2011 at 01:41:26PM +0900, YONETANI Tomokazu wrote:
> Apparently a few hours of pbulk test can trigger this panic (this is
> on x86_64 and the kernel is built from source as of 5347900e6).
> As opposed to what KKASSERT claims, p->p_lock doesn't hold the non-zero
> value in the frame 5:
>
:
> (kgdb) fr 5
> #5 0xffffffff802989a1 in kern_wait (pid=<value optimized out>,
> status=0xffffffe05e997a74, options=1528637672, rusage=0x0,
> res=0xffffffe05e997b58) at /usr/src/sys/kern/kern_exit.c:901
> 901 KKASSERT(p->p_lock == 0);
> (kgdb) p p->p_lock
> $1 = 0
After poking here and the, I think this KKASSERT() can simply go away
as proc_remove_zombie() will wait for p->p_lock to drop to zero anyway.
/*
* Unlink the proc from its process group so that
* the following operations won't lead to an
* inconsistent state for processes running down
* the zombie list.
*/
KKASSERT(p->p_lock == 0);
proc_remove_zombie(p);
leavepgrp(p);