> There needs some other changes if we decide to use mi_data_lock. Note > that mi_data_lock is hold when MAC's mi_unicst() callback is called, > and if the MAC calls mac_unicst_update() directly as the result of > mi_unicst(), it would cause deadlock. Serializing the mac clients control operations (mac_unicst_set) on a per mac endpoint basis will help us avoid holding mac layer data locks across the driver entry points. So mi_data_lock (I would prefer to collapse these data locks and use just 1 rw lock and 1 mutex lock per mac end point) can then be held just locally while operating on the mi_addr or whatever mac_impl_t member it is protecting. This is the approach I am taking with crossbow. But for now you could probably use mi_data_lock locally in the mac and use a different lock that is held across the driver entry points.
Thirumalai Cathy Zhou wrote: > >>> On a related note, it seems like some locking is missing from the >>> update >>> routines. For instance, mac_unicst_update() currently does a bcopy >>> () of >>> the new address into mi_addr without holding any locks. This issue >>> becomes magnified if we add the proposed checks. (Maybe Thiru has >>> some >>> thoughts on this?) >> >> Yep, mi_data_lock should do the job as Seb already pointed out. >> > There needs some other changes if we decide to use mi_data_lock. Note > that mi_data_lock is hold when MAC's mi_unicst() callback is called, > and if the MAC calls mac_unicst_update() directly as the result of > mi_unicst(), it would cause deadlock. > > Thanks > - Cathy
