> 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.
That's the behavior I saw back before I had the fix for 6508701 in my workspace. > 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. > > 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? That panicked my box -- which isn't really a surprise since we don't attach the NCE allocated by ire_nce_init() to the IRE until ire_add_v4(). -- meem
