Garrett D'Amore wrote:
So, given this, it is it safe for me to just call mac_{link,tx_notify()
while holding driver locks?
I would recommend that you not do this even though the code appears to
be safe for now. the reason is that you do not know what the notify
callback is going to do. it may somehow loopback down to the driver to
acquire the same lock you're holding.
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?
what's the problem with releasing the lock, then call mac_link_notify()?
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.
we're redesigning nemo's locking as part of the crossbow project. you
will hear more about this in several weeks time. for now, I'd suggest
that you try not to hold locks across any mac_* interface. if there are
issues with doing this, let us know and we'll take your needs into
account in our new design.
eric
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]
_______________________________________________
networking-discuss mailing list
[email protected]