From owner-cvs-src@FreeBSD.ORG  Thu Mar  3 22:33:46 2005
Return-Path: <owner-cvs-src@FreeBSD.ORG>
Delivered-To: cvs-src@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 169DE16A4CE; Thu,  3 Mar 2005 22:33:46 +0000 (GMT)
Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 44EA143D39; Thu,  3 Mar 2005 22:33:45 +0000 (GMT)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
	by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23MXidT011903;
	Thu, 3 Mar 2005 23:33:44 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: John Baldwin <jhb@FreeBSD.org>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Thu, 03 Mar 2005 11:16:22 EST."
             <200503031116.22840.jhb@FreeBSD.org> 
Date: Thu, 03 Mar 2005 23:33:44 +0100
Message-ID: <11902.1109889224@critter.freebsd.dk>
Sender: phk@critter.freebsd.dk
cc: Scott Long <scottl@samsco.org>
cc: src-committers@FreeBSD.org
cc: cvs-src@FreeBSD.org
cc: cvs-all@FreeBSD.org
cc: Daniel Eischen <deischen@FreeBSD.org>
cc: David Xu <davidxu@FreeBSD.org>
Subject: Re: cvs commit: src/sys/kern kern_sig.c 
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Mar 2005 22:33:46 -0000

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.