Merge branch 'bond_neigh_parms'
authorDavid S. Miller <davem@davemloft.net>
Fri, 2 Aug 2013 22:44:33 +0000 (15:44 -0700)
committerDavid S. Miller <davem@davemloft.net>
Fri, 2 Aug 2013 22:44:33 +0000 (15:44 -0700)
commit4b42df5da8c2f394adeaa61b23e9e58994b1c3c8
treee7dab36220c48573e4475034c9c68ce083219a93
parent8a849bb7f0ac513c2b7202620f611d94301c4a93
parent9918d5bf329d0dc5bb2d9d293bcb772bdb626e65
Merge branch 'bond_neigh_parms'

Veaceslav Falico says:

====================
Recent patches revealed an old bug, which was there for quite awhile. It's
related to vlan on top of bonding and ndo_neigh_setup(). When vlan device
is initiated, it calls its real_dev->ndo_neigh_setup(), and in case of
bonding - it will modify neigh_parms->neigh_setup to point to
bond_neigh_init, while neigh_parms are of vlan's dev.

This way, when neigh_parms->neigh_setup() of vlan's dev is called, the
bonding function will be called, which expects the dev to be struct
bonding, but will receive a vlan dev.

It was hidden before because of bond->first_slave usage. Now, with
Nikolay's conversion to list/RCU, first_slave is gone and we hit a null
pointer dereference when working with lists/slave.

First patch moves ndo_neigh_setup() in neigh_parms_alloc() to the bottom,
so that the ->dev will be available to the caller. It doesn't really change
anything, however is needed for the second patch.

Second patch makes bond_neigh_setup() (bond->ndo_neigh_setup()) check if
the neigh_parms are really from a bonding dev, and only modify the
neigh_setup in this case.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>