Network-related device drivers and MPSAFEty: status, and plans
for 7.0
Scott Long
scottl at samsco.org
Mon Jul 18 19:53:07 GMT 2005
Robert Watson wrote:
[...]
>
> if_dc Tulip driver -- mutexes present, not used unless IS_MPSAFE
> set to non-0, so un-exercised.
>
As has been discussed, throwing the switch on this one is scary since
the driver is so overloaded with parallel codepaths to handle slightly
incompatible hardware. Also, mutex recursion was often a common problem
with early locking attempts (due to the non-SMP-friendly design on
miibus). Do we know if this driver suffers from this or not?
>
> if_fxp Intel EtherExpress PRO/100 Ethernet device driver.
> Mutexes present and exercised; not marked IFF_NEEDSGIANT,
> but not marked INTR_MPSAFE (see if_fxpvar.h#define).
> Also, Giant passed into busdma for call-back lock. Maybe
> we can just throw the switch?
bus_dmamap_load_mbuf() doesn't do deferalls, so the mutex argument in
the tag is unused in this case. Don't take it as an indication of
Giant-ness. It would be good to put an appropriate lock into the tag
in case it's needed in the future. Or the lock arg can just be set to
NULL, NULL for now.
>
> if_hme Sun Microelectronics STP2002-STQ Ethernet interfaces
> device driver. Generally fine, but Giant referenced in
> budma callback. Can this be fixed easily?
See my comment on fxp.
>
> if_nve NVIDIA nForce MCP Networking Adapter device driver.
> Mutexes present and exercised; not marked IFF_NEEDSGIANT,
> but not marked INTR_MPSAFE. Also, busdma callbacks
> reference Giant. Maybe we can just throw the switch?
This driver has many many more problems that just locking.
> if_ti Alteon Networks Tigon PCI gigabit ethernet driver.
> Mutexes present and exercised, not marked MPSAFE.
I'm working on this one and using it as a testbed for alternate locking
strategies. The downside to this driver is that the initialization code
isn't quite right and results in making it very hard to use.
>
> if_owi Lucent Hermes, Intersil PRISM and Spectrum24 IEEE 802.11
> driver (old). Mutexes present and exercised, not marked
> MPSAFE.
Actually, I think that owi can be removed for 7.0. Maybe even 6.0. It
only existed as a stopgap for the 802.11 framework transition.
>
> if_aue, if_axe, if_cdce, if_cue, if_kue, if_rue, if_udav, if_ural
> Countless USB device drivers -- locking present,
> exercised, but all running under Giant, presumably due to
> the USB framework. Someone has a big TODO item here.
I don't think that we can assume that USB will get fixed for 7.0. It
would be nice if it does, but we shouldn't plan to orphan these drivers
because of it.
[...]
Scott
More information about the freebsd-arch
mailing list