> > > > > > Just to clarify - you previously mentionned you saw problems with 2.6.16 > > backport. Is this an issue you see with 2.6.20 as well? > Yes, the same thing happens with kernel 2.6.20. However, the patch for 2.6.20 > looks a little bit different. I will post it today or tommorow.
Let's see that first. I prefer to first look at upstream code, then think about backporting. > > > > Also - in your approach, what prevents the device from going away while > > there > > are still ipoib_neigh objects around? > Nothing prevents it. You can modprobe -r bonding whenever you want (even when > IPoIB is up) > and still be safe from leaks. I think my answer for that is below. > > > Also - if neigh does not point to ipoib device, our neigh destructor won't > > be called > > for it, will it? What will clean the ipoib neigh then? > > > With kernels up to 2.6.16, patch ipoib_8111_to_2_6_16 adds this to > ipoib_neigh_alloc > ==> neigh->neighbour->ops->destructor = ipoib_neigh_destructor; > So I guess there is no such problem here. But this would hardly help if ipoib module is unloaded while neighbour for bonding device is still around and has a pointer to ipoib_neigh_destructor. > For later kernels, bond device "borrows" the slave's neigh_setup > function in the bond's setup function. > > ==> bond_dev->neigh_setup = slave_dev->neigh_setup; > > So even if the beighbour points to bond device the > ipoib_neigh_destructor will be called. Same applies here. Further, in both cases, it seems that accessing data at to_ipoib_neigh on a neighbour for non-ipoib device can cause a crash if hardware address is !=0 at offset 20. -- MST _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general