Garrett D'Amore wrote:
But if the calling context is broken (by use of a taskq for instance),
then the risks you describe go away. Since that calling context is
already broken, I just would like a guarantee that it will *remain*
so. Then I can get away with this kind of approach. Otherwise I add
a lot of complexity or an additional context switch (taskq) into my
drivers. (Multiple drivers suffer this problem.)
Even before the taskq is used, the mac layer may have to acquire some
mac lock
say M1. Now if you are already holding a driver lock D1, the ordering is
D1 -> M1.
This imposes a requirement that we don't have M1 -> D1 anywhere in the code.
So this becomes an exception to the general rule that locks may be held
across layers
in the downcall, and you have to filter out M1 -> D1. Using a taskq in
the driver instead,
avoids the exception itself. As the number of exceptions increase, the
locking becomes
unmanageable.
And yes, my suggestion does add a small amount of complexity to the
*rules* for drivers (an exception for a few mac_xxx_update entry
points), but the gain is the removal of significant complexity or
additional context switches in the device drivers.
Sure, we can look at that, and try to work out just this one case of
mac_xxx_update,
to the extent possible, but please don't make any assumptions based on
the current
implementation, and try to extend this in all generality.
I'll trade complexity in the framework for elimination of that
complexity in drivers (repeated across multiple drivers.)
To an extent yes, but not to the extent that it becomes impossible to
maintain the framework.
Thirumalai
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
