> Seems like that code relies on there never being an NCEs sitting around in
> other states when ndp_lookup_then_add() is called.  For instance, if ce1
> has an NCE for H, but it is in the ND_INITIAL state (perhaps because
> nce_reinit() got called?), then it will get left in the ND_INITIAL state
> -- and ire_add_v4() will find it != ND_REACHABLE and discard.

Something else is wrong.
Why would the nce for H be in ND_INITIAL, when the nce for G is not?
And why would this happen for every single attempt through ip_newroute()
for H? Is nce_reinit() actually being called?

> Is there something that prevents this case from happening in Nevada?

Even if the timing worked out so that nce_reinit occurred between the
ire_nce_init() and the ire_add_then_send(), the system should recover:
both the nce for G and H will be reinit-ed, so the next ip_newroute()
for H will get back an INTERFACE ire from ire_ftable_lookup, and we
should go back to doing the "arp for G, then add ire_cache for H" 
sequence.

--Sowmini


Reply via email to