Re: Ethernet driver teardown

From: M. Warner Losh (imp_at_bsdimp.com)
Date: 10/03/05

  • Next message: Brooks Davis: "Re: error in trimdomain(3)"
    Date: Mon, 03 Oct 2005 11:25:26 -0600 (MDT)
    To: jhb@FreeBSD.ORG
    
    

    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
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


  • Next message: Brooks Davis: "Re: error in trimdomain(3)"

    Relevant Pages

    • Ethernet driver teardown
      ... I was thinking about the problem with ethernet driver detach races this ... What if the sequence for detachwas altered such ...
      (freebsd-arch)
    • Re: AMD Geode LX crypto accelerator (glxsb) (and padlock.ko)
      ... padlock and glxsb may not reuse the free sessions. ... "Initialize our task queue" comments. ... You need to do a taskqueue_drainin your detach routine before ... You should do a callout_drainrather than a callout_stopin your detach ...
      (freebsd-current)