Date: Fri, 14 Nov 2003 14:03:08 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: RE: cvs commit: src/sys/sys proc.h Message-ID: <XFMail.20031114140308.jhb@FreeBSD.org> In-Reply-To: <XFMail.20031114130219.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14-Nov-2003 John Baldwin wrote: > > On 14-Nov-2003 John Baldwin wrote: >> jhb 2003/11/14 08:27:17 PST >> >> FreeBSD src repository >> >> Modified files: >> sys/sys proc.h >> Log: >> Add a WITNESS_WARN() check to _STOPEVENT() since any _STOPEVENT() can >> potentially sleep. This should help find some bogus locking. > > There is at least one place where sigacts locking trips this assertion. > I will try to work on cleaning up that and other problems that surface > today from this check. > > I also need to add a KASSERT() to msleep/cv_wait* that we don't try > to sleep if we are already on a sleep queue. It seems that using > ptrace can trip that as well. :( Also, this last is also a bug in 4.x, though I think perhaps it is a feature. Basically, in msleep() in both branches, we put a thread/proc on the sleep queue before checking for signals(). If during checking signals we are woken up, we don't sleep but return immediately. Thus, if during checking for signals we sleep because of a stop event, we just won't ever sleep on the original wait channel but will return to recheck the condition in a while loop. However, I am curious if the linkages of the sleep queues can be broken by taking a thread that is already on a sleep queue and sticking it on another sleep queue. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20031114140308.jhb>