Date: Thu, 03 Mar 2005 23:33:44 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: John Baldwin <jhb@FreeBSD.org> Cc: David Xu <davidxu@FreeBSD.org> Subject: Re: cvs commit: src/sys/kern kern_sig.c Message-ID: <11902.1109889224@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 03 Mar 2005 11:16:22 EST." <200503031116.22840.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200503031116.22840.jhb@FreeBSD.org>, John Baldwin writes: >On Thursday 03 March 2005 10:21 am, Daniel Eischen wrote: >> 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? > >Just because you sleep on a stack address doesn't mean that you are going to >write to that object when doing a wakeup. However, it might not be a bad >idea as stack address can be indicative of bugs like this: In some cases the guaranteed anonymity of stack variables is actually a benefit. See for instance the protective mutexes used #ifdef DIAGNOSTIC in g_up(), g_down() and when calling callouts(). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11902.1109889224>