[email protected] wrote: > On Thu, Jul 09, 2009 at 07:21:34PM +0300, Yossi Etigin wrote: >> .... >> The path itself is rarely used, most of the time we take the ah from the >> ipoib_neigh which is stashed in the kernel neighbour. >> The scenario is that ipoib_start_xmit() runs after the flush task releases >> the lock, and does 'neigh = *to_ipoib_neigh(skb_dst(skb)->neighbour)'. >> Then the flush task continues to run and does path_free() which calls >> ipoib_neigh_free(), and kfree-s the neighbour. Then the xmit routine >> will go on using a stale neigh pointer. >> > > This does seem possible, no? > > If so, it would be addressed by the patch I sent here: > > http://lists.openfabrics.org/pipermail/general/2009-July/060501.html > > because the ipoib_neigh structure wouldn't be freed until after > ipoib_start_xmit() had done rcu_read_unlock(). >
Yes, I guess it would address the ipoib_neigh structure problem. But then neigh->ah might be freed while xmit is using it. _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
