[ofa-general] Re: A question about tx lock in ipoib_flush_paths

[Yossi Etigin]

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