[openib-general] [PATCH] IB/ipoib: Add field dev to struct ipoib_neigh

[Michael S. Tsirkin]

> > 
> > 
> > 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