Garrett D'Amore wrote:
I understand this. But in this particular case, the lock M1 is a leaf
lock, all the locks are safe. And it would, IMO, be a bad idea to
change this part of nemo.
You are basing this on the current implementation. We are redoing the
locking,
and may coalesce some locks. So what appears as a leaf lock, may not
be so later on. Note that I said 'M1' and not i_mac_impl_lock. If you
assume it
is i_mac_impl_lock or mi_lock then it makes you think it is a leaf lock.
Of course. But in this case, no complexity is actually being
increased in the framework. Only a reasonable promise that the
current reasonable asynchronous disassociated implementation of
mac_xxx_update be retained.
The isssue is about the mac layer locks that have to be grabbed before
the taskq call is made.
and please read this with my response above.
Believe me, if I could see any compelling reason to break that promise
in the framework, I wouldn't be asking for it. But the code paths we
are talking about are all off the hot code paths, and the
simplification actually shortens and simplifies some hot-path code for
device drivers, so its all upside _in this particular case_. I'm not
asking for a general rule, only a specific exception for mac_tx_update
and mac_link_update. (And even mac_link_update might not really be as
important, but mac_tx_update will save a lot of complexity in e.g. my
hme -> gldv3 port.)
I understand your need, Please give us some time. We will try to see if
and/or how we can handle this single exception in our new locking model.
Thirumalai
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
