[ofa-general] [RFC] ipoib: avoid using stale ipoib_neigh* in ipoib_neigh_cleanup()

[Or Gerlitz]

akepner at sgi.com wrote:
> We've seen a few instances of a crash in ipoib_neigh_cleanup() due to the use of a stale pointer:
> 848         neigh = *to_ipoib_neigh(n); <- read neigh (no locking)
> .....
> 858         spin_lock_irqsave(&priv->lock, flags);
> 860         if (neigh->ah) <--- at this point neigh may be stale
[...]
> I've been looking into a proper fix for this, and I'd like to solicit any ideas. 

Before going into possible solutions, could you say what kernel are you using? 

With this or related problems being around for couple of years, I always wanted to understand (A) why access to from-the-kernel-point-of-view-to-be-destructed-neighbour be protected? and (B) how come it can becomes stale? before 2.6.17-20 or so this could have happen since the ipoib neighbour destructor could have been called for NON ipoib neighbours - which for my understanding isn't the case any more in modern kernels see commit ecbb416939da77c0d107409976499724baddce7b "[NET]: Fix neighbour destructor handling"

Or.