cvs commit: src/sys/kern kern_sig.c
nate at root.org
Thu Mar 3 12:04:17 PST 2005
John-Mark Gurney wrote:
> Daniel Eischen wrote this message on Thu, Mar 03, 2005 at 10:21 -0500:
>>On Thu, 3 Mar 2005, Scott Long wrote:
>>>It's not about convenience or taking the easy way out. Let's fix
>>>sigwait() to have the proper assumptions and go from there. I'm
>>>inclined to agree with John that the problem is not widespread or
>>>impossible to track down. Fixing it is not hard either, we already have
>>>the PHOLD()/PRELE() functions for doing exactly what is needed here.
>>Can you add assertions in msleep(), cv_wait(), etc, to
>>panic if the object is on the kernel stack and the
>>stack is swappable?
> This won't detect another class of bugs that was found in the kqueue
> code... kqueue used to allocate a sentinal and put it on a list,
> and then go to sleep with that sentinal on the list...
> So, I'd say having an option to unmap the kernel pages at msleep time
> (like someone else suggested) would be a much more versitile way of
> ensuring we find these bugs.. Then we can also issue a warning about
> one thread trying to access another thread's stack (when it's sleeping)...
That was me. At work, we've done a lot of intentional fault injection
in software we were evaluating and this kind of thing is very helpful.
Note also silby@'s work in extremely pessimizing fragmentation to work
out bugs in our reassembly code.
On a side note, I really appreciate Peter Holm's effort in doing stress
testing of -current. That along with des@'s tinderbox builds has made a
lot of progress toward automated validation of our tree.
More information about the cvs-all