Date: Thu, 3 Mar 2005 11:02:06 -0800 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: Daniel Eischen <deischen@freebsd.org> Cc: David Xu <davidxu@freebsd.org> Subject: Re: cvs commit: src/sys/kern kern_sig.c Message-ID: <20050303190206.GZ89312@funkthat.com> In-Reply-To: <Pine.GSO.4.43.0503031020180.2058-100000@sea.ntplx.net> References: <422719E0.10703@samsco.org> <Pine.GSO.4.43.0503031020180.2058-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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)...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050303190206.GZ89312>