[email protected] 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. _______________________________________________ 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
