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]

Reply via email to