> So if I understand what you're describing correctly, you're worried about
> the DL_NOTE_PHYS_ADDR that will be generated by the underlying driver
> when softmac itself does a DL_PHYS_ADDR_REQ in softmac_m_unicst(), right?
Mostly. I'm worried that we can't always ignore that DL_NOTE_PHYS_ADDR
because the address change may not have been via the GLDv3 (softmac) node
-- but if we always just do a mac_unicst_update(), in the common case the
result will be two DL_NOTE_PHYS_ADDRs (one by the GLDv3 framework, and one
by softmac's mac_unicst_update() call).
> > 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?)
>
> It looks like mi_addr should be protected by mi_data_lock (from looking
> at mac_unicst_{get,set}()). mac_header() would also need to be changed
> to hold that lock.
Yep.
--
meem
