> >> 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.
I'd suggest that we add the check to mac_unicst_update() as part of UV but leave the locking issues to another CR, as they are pre-existing and may well be resolved by the reworked Crossbow locking design. -- meem
