From owner-cvs-src@FreeBSD.ORG Thu Mar 3 22:15:01 2005 Return-Path: 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 5D3B016A4D0 for ; Thu, 3 Mar 2005 22:15:01 +0000 (GMT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01BA943D41 for ; Thu, 3 Mar 2005 22:15:00 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 31891 invoked from network); 3 Mar 2005 22:15:00 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 3 Mar 2005 22:14:59 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j23MEqDs092866; Thu, 3 Mar 2005 17:14:53 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Daniel Eischen Date: Thu, 3 Mar 2005 11:16:22 -0500 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503031116.22840.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: cvs-src@FreeBSD.org cc: Scott Long cc: src-committers@FreeBSD.org cc: David Xu cc: cvs-all@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 22:15:01 -0000 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: foo(void *bar, ...) { msleep(&bar); } rather than doing foo(void *bar, ...) { msleep(bar); } -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org