I'm interested in using mac_link_update and mac_tx_update from a few
contexts where I'm currently holding some driver-specific locks. (E.g.
link lock , xmit lock.)
Going over the code, it _appears_ that this is probably safe. It looks
like these routines arrange to use a taskq_dispatch (via i_mac_notify())
to deliver the final message.
The only potential problems I see are these two locks:
i_mac_impl_lock
mip->mi_notify_ref_lock
My analysis is that the first lock, which is a RW lock, is acquired as a
reader i_mac_notify(), and is used to protect the list of registered
modules. (It is acquired as a writer in mac_register, unregister, and
as a reader in i_mac_info_get.) Therefore, assuming I don't hold any
locks across my calls to mac_register and mac_unregister (which would be
a _really_ bad idea), it looks like this is safe.
The second lock is mip->mi_notify_ref_lock, which appears to be a leaf
lock, and thus completely safe. (Technically, since cv_signal/cv_wait
is called with this lock, its not a true leaf lock, but for the purposes
of this discussion it can be considered to be one.)
So, given this, it is it safe for me to just call mac_{link,tx_notify()
while holding driver locks? Or must I go to contortions (such as adding
my own driver taskq, or a soft interrupt) to ensure that I never call
this while holding a driver specific lock? Will this guarantee hold
true going forward? Obviously, since it does a lot to simplify driver
design, and eliminate extra context switches, I'd really prefer to be
able to rely on this behavior.
Also, note that this is only for code integrated into ON at this time.
:-) I realize _no_ guarantees are made for code that isn't part of ON.
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
