> > > Ok. So I guess there are no tests in the ipmp test suite to trigger this > > particular case. > > > > > Is it possible that: > > > 6508701 ire_add_v4() often adds unresolved IREs even when told not to > > > ... is playing a role here? Specifically, before that fix, ire_add_v4() > > > will add unresolved IREs regardless of the allow_unresolved flag. So > > > > nope. the root-cause is different. even if you add the ire, unless > > someone kicked off arp, the packets would never get sent. > > I thought that ip_xmit_v4() would kick that off via ire_arpresolve() the > next time someone sends a packet through that IRE.
Is ip_xmit_v4 getting invoked for this packet if the changes from CR 6508701 are masked out? It is possible that CR 6508701 may have masked this problem, though. Also, another thing that occurred to me later: we can't rely on passing in a non-null ire_fp_mp from ip_newroute() to ensure that the returned nce for H is REACHABLE: there may be cases where fastpath for save_ire in ip_newroute() is not completed yet. So the correct solution is to always mark the returned NCE to be reachable in ip_newroute for the IRE_CACHE case and trigger fastpath for it. > Well, it's trivially easy to encounter on my test machine with my bits -- The fix is not that complex. I think the following two lines 8666 } + ire->ire_nce->nce_state = ND_REACHABLE; + nce_fastpath(ire->ire_nce); 8667 ire_add_then_send(q, ire, xmit_mp); should take care of it. Can you please verify? --Sowmini
