Sebastien Roy wrote:
On 01/21/10 12:34 AM, Peter Memishian wrote:
> Lots of drivers call mac_unregister(), and *then* disable
callbacks,
> interrupts, etc.
>
> This makes sense, because you don't want to tear all that stuff
down if
> the mac is going to refuse to detach because its busy.
This is why Seb introduced mac_disable() a while back. Once
mac_disable()
succeeds, you can be certain mac_unregister() will not fail.
Indeed. The remaining work would be to make use of it in drivers that
contain those potential races.
I've filed a bunch of bugs. All ethernet drivers, from what I can tell,
suffer from this bug.
Its amazing it hasn't created field problems. I guess DDI_DETACH
operations are not very common....
I'll be fixing a bunch of them.
I almost wonder if we should just mac_disable() a mandatory part of the
API, and cmn_err(CE_WARN) on mac_unregister if mac_disable() has not
been called first. At least in debug builds. First we need to fix the
drivers.
(Is there any driver that reasonably calls mac_unregister but
*shouldn't* call mac_disable first? I'm skeptical that there is any.)
- Garrett
-Seb
_______________________________________________
networking-discuss mailing list
[email protected]
