Re: panic: assertion: p->p_lock == 0 in kern_wait

[YONETANI Tomokazu <y0n3t4n1@xxxxxxxxx>]

On Sun, Apr 24, 2011 at 11:36:27AM +0900, YONETANI Tomokazu wrote:
> >      With regards to getting rid of the timeout in the tsleep and using a
> >      proactive wakeup(), we have to avoid calling wakeup() for 1->0
> >      transitions unless someone is known to be waiting on p_lock.  This
> >      can be implementing by adding a WAITING flag to the field and using
> >      atomic_cmpset_int() to handle the (WAITING | 1) -> (0) transition and
> >      then calling wakeup() if WAITING was set.
> > 
> >      I will augment the sys/refcount.h API and add refcount_wait() and
> >      refcount_release_wakeup() which encapsulate the appropriate atomic
> >      ops.  I will leave it up to you if you want to then use the new API
> >      functions for PHOLD/PRELE, which would give the tsleep case a
> >      proactive wakeup() instead of having to wait for it to timeout.
> 
> So what I need to do is to change PHOLD/PRELE to use refcount_acquire/
> refcount_release_wakeup and replace p->p_lock loop with
> refcount_release_wakeup?  I'll give it a try.
 
I've been running the kernel with patch(es) attached to this message
and so far it's running fine under load.  It reduced the number of
non-zero p->p_lock just before calling proc_remove_zombie() even without
holding proc_token around the first wait loop.  However I've observed
a panic when a signal is sent to a process group, and I need to determine
if it's jail related or GNU screen related.

Best Regards,
YONETANI Tomokazu.