From owner-freebsd-current@FreeBSD.ORG Sat May 5 02:26:59 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A814616A401; Sat, 5 May 2007 02:26:59 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 3778613C458; Sat, 5 May 2007 02:26:59 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l452QuHE075459; Fri, 4 May 2007 20:26:56 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <463BEB6C.90507@samsco.org> Date: Fri, 04 May 2007 20:26:52 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: John Baldwin References: <463B7A1D.6020602@omnisec.de> <200705041637.38955.jhb@freebsd.org> <463B9C7E.2080901@samsco.org> <200705041748.56842.jhb@freebsd.org> In-Reply-To: <200705041748.56842.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 04 May 2007 20:26:56 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: attilio@freebsd.org, freebsd-current@freebsd.org, Harald Schmalzbauer Subject: Re: PANIC: blockable slep lock (sx) msi @ ....msi.c:374 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2007 02:26:59 -0000 John Baldwin wrote: >> Well, you were just using it as a hack around a WITNESS warning ;-) I >> think it's OK for memory allocations to fail in this kind of code, so >> long as the failure is propagated to the caller. > > Do you really expect bus_alloc_resource()-type things to fail to attach a > driver instead of waiting for the system to free up some memory? Most of > that sort of thing is quite resilient right now, and I'm hesitant to make the > system start breaking things instead of waiting when memory runs low. > That's actually a very good question. Most core newbus and resource list functions already fail for lack of memory, so any guarantees about device device discovery, probe, and attach are already inconsistent. However, making guarantees is perfectly fine, I don't have a problem with that. But along with that, clients need to know what to expect from these utility/infrastructure subsystems in terms of locking and blocking. These subsystems also need to be conscious of being as consistent and easy to work with as possible, in line with the guarantees that are offered. The panic that you introduced is a perfect example of what happens when there aren't clear definitions and guarantees, and that's what I'm most concerned about fixing. I think it's good practice to have these subsystems do the following: 1. Do not hold private locks over calls to client subsystems. 2. Avoid blocking and sleeping except where specifically designed and documented to do so. 3. Report all errors up to the caller, avoiding panics where possible. If you think of kernel infrastructure as being similar to userland libraries, where both provide services and utilities to client code, then these rules make a lot of sense. As Giant gets removed from more of this code, better care and planning gets much more important. Scott