[ofa-general] [RFC] ipoib: avoid using stale ipoib_neigh* in ipoib_neigh_cleanup()
ogerlitz at Voltaire.com
Wed May 20 00:14:34 PDT 2009
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"
More information about the general