From owner-freebsd-current@FreeBSD.ORG Thu Sep 22 11:04:36 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89CA916A41F; Thu, 22 Sep 2005 11:04:36 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C46143D46; Thu, 22 Sep 2005 11:04:36 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id C0CBA46BA0; Thu, 22 Sep 2005 07:04:35 -0400 (EDT) Date: Thu, 22 Sep 2005 12:04:35 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <200509211639.29092.jhb@FreeBSD.org> Message-ID: <20050922120322.K34322@fledge.watson.org> References: <4cf221cc050919133065a611b7@mail.gmail.com> <200509211639.29092.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Bjoern A. Zeeb" , Erik Winge , freebsd-current@freebsd.org Subject: Re: lor in in.c and if_ural.c 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: Thu, 22 Sep 2005 11:04:36 -0000 On Wed, 21 Sep 2005, John Baldwin wrote: > On Monday 19 September 2005 05:08 pm, Bjoern A. Zeeb wrote: >> On Mon, 19 Sep 2005, Erik Winge wrote: >>> I got this lock order reversal on 7.0-CURRENT today: >>> >>> lock order reversal: (Giant after non-sleepable) >>> 1st 0xc06aaea0 in_multi_mtx (in_multi_mtx) @ >>> /usr/src/sys/netinet/in.c:964 2nd 0xc065dee0 Giant (Giant) @ >>> /usr/src/sys/dev/usb/if_ural.c:1401 >> >> for the archives: I added this with LOR ID 162. See >> http://sources.zabbadoz.net/freebsd/lor.html#162 > > This LOR is going to happen with every non-MPSAFE network driver for > now. Actually, this one is a little different -- the one you're thinking of is the Giant acquisition in in.c, but this is in fact Giant acquisition in the device driver itself, in its ioctl routine. Device drivers Should Not Do That, but likely do because otherwise they fail Giant assertions. We should fix those callers to acquire Giant, or fix all device drivers (or both?). Robert N M Watson