On 07/09/2007, Thirumalai Srinivasan <[EMAIL PROTECTED]> wrote: > If there are indeed upstream callers, mi_ref is non-zero and > mac_register will fail. So it should be sufficient, if the driver > quiesces the chip, and become single threaded on the mac endpoint before > calling mac_unregister to avoid the race. Another question, what does > xxx_m_stop really mean ? Why can't the driver quiesce everything at this > point itself ? If mac_unregister() succeeds, it implies that an > xxx_m_stop has happened before that. It doesn't seem right if we can > still have upcall threads and notifications going on even after > mac_stop() has finished successfully.
This is probably my source of confusion on this topic. I was assuming that the m_stop() entry was being implemented correctly and was quiescing things. If it is not then I can indeed see that there may be outstanding threads when mac_unregister() is called. Paul -- Paul Durrant http://www.linkedin.com/in/pdurrant _______________________________________________ networking-discuss mailing list [email protected]
