cvs commit: src/sys/dev/re if_re.c
ru at freebsd.org
Fri Sep 16 02:19:18 PDT 2005
On Thu, Sep 15, 2005 at 11:56:39PM +0300, Ruslan Ermilov wrote:
> The first is the BPF detach bad interaction with foo_detach(),
> as described in re_detach(). This panic is real with (I think)
> all drivers. And testing IFF_DRV_RUNNING here doesn't seem to
> be able to prevent the panic. Perhaps the fix would be to
> move ether_ifdetach() before foo_stop() in foo_detach(), I'm
> not yet sure.
I tried with rl(4) PCCARD, by moving ether_ifdetach() before
rl_stop() in rl_detach(). It fixes the panic when you eject
the card, but doesn't fix it when kldunloading the module.
The difference is that rl_detach() is called already after
miibus0 and rlphy0 has been detached when kldunloading the
module. When ejecting the card, rl_detach() is called first.
What happens when you kldunload the module with BPF listener
attached, is that bpfdetach() calls rl_ioctl() to reset
promisc, that calls rl_init_locked(), and that results in
mii = device_get_softc(sc->rl_miibus);
being NULL (remember the miibus has already been detached),
and that panics later here:
When we reset IFF_UP, rl_ioctl(SIOCSIFFLAGS) silently exits
and no harm is done. So the question is: how do we prevent
this from happening without resetting IFF_UP. One possible
solution would be to add sc->detaching, similar to
sc->suspended, abd check it in rl_ioctl().
ru at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20050916/b6364911/attachment.bin
More information about the cvs-src