Date: Thu, 22 Sep 2005 12:04:35 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, Erik Winge <erik.winge@gmail.com>, freebsd-current@freebsd.org Subject: Re: lor in in.c and if_ural.c Message-ID: <20050922120322.K34322@fledge.watson.org> In-Reply-To: <200509211639.29092.jhb@FreeBSD.org> References: <4cf221cc050919133065a611b7@mail.gmail.com> <Pine.BSF.4.53.0509192107070.36713@e0-0.zab2.int.zabbadoz.net> <200509211639.29092.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050922120322.K34322>