>>> Using to_ipoib_neigh outside priv->lock looks problematic. >>> Can you convince me this does not introduce new races? >>> >>> >> I can try... >> ipoib_neigh_destructor is called from neigh_destroy() and this is when the >> kernel neighbour is under destruction itself and no one holds a reference to >> it. > > OK but we might have references to ipoib_neigh. Specifically path and mcast > group all might have it - that's what neigh_list is. > Maybe I'm not get something but how does the presence of ipoib_neigh on the list is a problem? to_ipoib_neigh() takes the pointer from the neighbour itself without caring if it is on a list or not. Destruction itself is being done under lock.
>> My opinion is that if I can't assume that no one is touching ipoib_neigh >> when kernel >> neighbour is being destroyed then we have a bigger problem. > > That's what locks you remove seem to be there for. > _______________________________________________ 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
