Jay Vosburgh [off-list ref] writes:

	No, to both questions.  Also, if I back out the 7 bonding
patches, the same insmod / rmmod does not panic.  

	I just set it up and did it again.  Fresh boot of the system
(which doesn't load bonding); "insmod drivers/net/bonding/bonding.ko;
rmmod bonding" and blammo.

	A little bisect action reveals that the problem first appears
after applying the fifth patch (below).  Does a basic insmod / rmmod
cycle work ok for you?  I'm specifying no options to bonding.

It works here.  The only issue I found was that veth wasn't quite
working.   I am wondering if there was some version of the tree
where rtnl_link_unregister is broken and you applied the patches to that.

I tested the net-next tree with my patches at the top:

There are some other differences like I am running a 64bit kernel but
I don't expect that would make a difference in practice.

Eric

commit 6639104bd826e0b1388c69a6b7564fffc636c8a8
Author: Eric W. Biederman [off-list ref]
Date:   Thu Oct 29 23:58:54 2009 +0000

    bond: Get the rtnl_link_ops support correct
    
    - Don't call rtnl_link_unregister if rtnl_link_register fails
    - Set .priv_size so we aren't stomping on uninitialized memory
      when we use netdev_priv, on bond devices created with
      ip link add type bond.
    
    Signed-off-by: Eric W. Biederman [off-list ref]
    Signed-off-by: David S. Miller [off-list ref]