From owner-cvs-all@FreeBSD.ORG Thu Mar 3 20:04:16 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1F8D16A4CE; Thu, 3 Mar 2005 20:04:16 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10C7A43D48; Thu, 3 Mar 2005 20:04:16 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j23K46Zj027132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Mar 2005 12:04:07 -0800 Message-ID: <42276DB6.8030701@root.org> Date: Thu, 03 Mar 2005 12:04:06 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John-Mark Gurney References: <422719E0.10703@samsco.org> <20050303190206.GZ89312@funkthat.com> In-Reply-To: <20050303190206.GZ89312@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Scott Long cc: src-committers@freebsd.org cc: John Baldwin cc: cvs-src@freebsd.org cc: cvs-all@freebsd.org cc: Daniel Eischen cc: David Xu Subject: Re: cvs commit: src/sys/kern kern_sig.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 20:04:17 -0000 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