Date: Sun, 18 Jul 2004 19:57:11 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Brian Fundakowski Feldman <green@freebsd.org> Cc: FreeBSD current mailing list <freebsd-current@freebsd.org> Subject: Re: kldunload if_sk -> LOR & panic Message-ID: <Pine.BSF.4.53.0407181955250.43309@e0-0.zab2.int.zabbadoz.net> In-Reply-To: <20040718193513.GV1626@green.homeunix.org> References: <Pine.BSF.4.53.0407181443330.43309@e0-0.zab2.int.zabbadoz.net> <20040718193513.GV1626@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 18 Jul 2004, Brian Fundakowski Feldman wrote: > On Sun, Jul 18, 2004 at 03:11:22PM +0000, Bjoern A. Zeeb wrote: > > Hi, > > > > tried to unload if_sk for testing the newly built module with dwhite's > > locking patch (will be loaded after reset now :( ). > > resulted in this on my amd64: > > > > --- cut --- > > noc# kldunload if_sk > > e1000phy0: detached > > miibus0: detached > > lock order reversal > > 1st 0xffffff0030ac7870 skc0 (network driver) @ sys/pci/if_sk.c:2604 > > 2nd 0xffffff0000b91af0 radix node head (radix node head) @ sys/netinet/in_rmx.c:391 > > Stack backtrace: > > witness_checkorder() at witness_checkorder+0x4a6 > > _mtx_lock_flags() at _mtx_lock_flags+0x39 > > in_ifadown() at in_ifadown+0x5b > > in_control() at in_control+0x81c > > if_detach() at if_detach+0x50b > > ether_ifdetach() at ether_ifdetach+0x25 > > sk_detach() at sk_detach+0x6d > > (null)() at 0 > > null_method() at null_method > > At the point where it's actually detaching, once it's detached the methods > that access its softc, it should drop its softc lock before calling the > network-level detach routines. I think this is handled by dwhite's patch so I should be safe now. Perhaps someone could work towards committing a cleaned up version of this patch ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.53.0407181955250.43309>