Date: Mon, 03 Oct 2005 11:25:26 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: jhb@FreeBSD.ORG Cc: arch@FreeBSD.ORG, ru@FreeBSD.ORG Subject: Re: Ethernet driver teardown Message-ID: <20051003.112526.102577313.imp@bsdimp.com> In-Reply-To: <200510031246.14835.jhb@FreeBSD.org> References: <200510031246.14835.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200510031246.14835.jhb@FreeBSD.org>
John Baldwin <jhb@FreeBSD.org> writes:
: So, I was thinking about the problem with ethernet driver detach races this
: morning and had an idea. What if the sequence for detach() was altered such
: that we called ether_ifdetach() before the driver's stop() routine? Thus,
: you would end up with something like this:
:
: foo_detach()
: {
:
: ether_ifdetach(sc->foo_ifp);
: FOO_LOCK(sc);
: foo_stop(sc);
ifp->if_drv_flags &= ~IFF_DRV_RUNNING; /* or does foo_stop do this? */
: FOO_UNLOCK(sc);
: callout_drain(...);
: bus_teardown_intr(...);
: if_free(sc->foo_ifp);
: bus_release_resources(...);
: ...
: }
:
: Would that solve the various races including letting BPF turn off promiscuous
: mode cleanly without requiring detaching flags in each driver to bail out of
: foo_ioctl()?
I'm unusure. I'm prettys sure that the promisc mode would be turned
off correctly, but see below.
This does represent an improvement over the current method. I have a
couple of concerns.
(1) What happens to the packets received when the device is detached.
We'll have to make sure that the ifp is in a state that can allow
for the input routine to still be called w/o leaking memory.
(2) Does this solve the problems that I originally suggested a
if_dead() routine for?
(3) How do we know that we're out of all the ifp callbacks when
ether_ifdetach() returns? If we forced a lock/unlock pair for all
ioctl functions, then we could know for sure when we acquire the
lock. I'm unsure what to do about if_output, if_start and
if_watchdog.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051003.112526.102577313.imp>