Date: Tue, 7 Jan 2003 13:09:01 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: "M. Warner Losh" <imp@bsdimp.com> Cc: tlambert2@mindspring.com, nate@root.org, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Proper -current if_attach locking? Message-ID: <15899.6077.710661.497492@grasshopper.cs.duke.edu> In-Reply-To: <20030107.105933.19259527.imp@bsdimp.com> References: <20030107.021428.126452776.imp@bsdimp.com> <20030107.022617.23700606.imp@bsdimp.com> <15898.60467.681434.927797@grasshopper.cs.duke.edu> <20030107.105933.19259527.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh writes: > In message: <15898.60467.681434.927797@grasshopper.cs.duke.edu> > Andrew Gallatin <gallatin@cs.duke.edu> writes: > : The IFNET_RLOCK() called in if_slowtimo() is a global lock for the > : list of ifnet structs to ensure that no devices are removed or added > : while something may be using it. There is one ifnet list in the system. > > So this means that only the locking in attach is bogus, and similar > locking in detach is also bogus because they produce lock order > reversals as the global lock is held to insert/remove if interfaces. Yes. Though I haven't looked at if_dc myself, there may be other locking problems. I've only been commenting on the ones that you brought up. But back to an earlier point. Somebody (you?) validly pointed out that the driver should not be callable and should not generate interrupts until its finished attaching. The lock in its attach was probably a somewhat misguided attempt at that. The first point can be accomplished by doing the ether_ifattach() last, but the second may be harder. I do that by poking a bit on my card which prevents it from generating interrupts while the device is being setup. Not sure if a similar bit exists on tulip cards. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15899.6077.710661.497492>