Date: Tue, 07 Jan 2003 13:58:10 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: gallatin@cs.duke.edu Cc: tlambert2@mindspring.com, nate@root.org, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Proper -current if_attach locking? Message-ID: <20030107.135810.92265343.imp@bsdimp.com> In-Reply-To: <15899.6077.710661.497492@grasshopper.cs.duke.edu> References: <15898.60467.681434.927797@grasshopper.cs.duke.edu> <20030107.105933.19259527.imp@bsdimp.com> <15899.6077.710661.497492@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <15899.6077.710661.497492@grasshopper.cs.duke.edu>
Andrew Gallatin <gallatin@cs.duke.edu> writes:
:
: 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.
Yes. That was me. There are some drivers that have separated
front/back ends that makes this harder, but most of them don't.
: 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.
All PCI cards have to be able to turn off their interrupt sources,
otherwise interrupt storms result. At least that's my understanding.
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030107.135810.92265343.imp>