Date: Thu, 03 Mar 2005 12:04:06 -0800 From: Nate Lawson <nate@root.org> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: David Xu <davidxu@freebsd.org> Subject: Re: cvs commit: src/sys/kern kern_sig.c Message-ID: <42276DB6.8030701@root.org> In-Reply-To: <20050303190206.GZ89312@funkthat.com> References: <422719E0.10703@samsco.org> <Pine.GSO.4.43.0503031020180.2058-100000@sea.ntplx.net> <20050303190206.GZ89312@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42276DB6.8030701>