Roland Dreier wrote: > > Couldn't ipoib_start_xmit() grab ipoib_neigh, and cause the same thing the > > commit above was intended to fix? > > I don't see how -- either ipoib_start_xmit runs before the flush task > grabs the tx lock, in which case it uses the path and exits before the > flush task runs, or ipoib_start_xmit runs after the flush task releases > the lock, in which case the path is already removed from the path rbtree > and hence won't be found by ipoib_start_xmit. Of course I could easily > be missing something.
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. --Yossi _______________________________________________ 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
