DragonFly bugs List (threaded) for 2011-04
Re: panic: assertion: p->p_lock == 0 in kern_wait
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.