On Fri, 2016-09-02 at 08:57 -0600, David Ahern wrote: > I hit this same problem yesterday but with the bridge. I forgot I had > a macvlan device on an interface and tried to enslave it to a bridge. > It failed with EBUSY without crashing the kernel so it is one example > that handles the conflict, and the bridge also calls the register > before the enslaving is done. >
Sure, some netdev_rx_handler_register() users are simpler than bonding, this was the point Jiri raised. Hey guys just use team instead of bonding ;) If you carefully look at bridge code, you'll find other kind of errors for sure ;) For example, should dev_disable_lro() be called before or after netdev_rx_handler_register() ? ;) Mahesh proposal allows for simplification, since one level can be removed from the error rollback chain. Ideally the netdev_rx_handler_register() should be called only when no further errors can be detected in the 'enslaving' process, otherwise some live packets could come and be incorrectly processed/dropped by a not fully initialized driver. So it is a chicken and egg problem, if you allow netdev_rx_handler_register() to return an error, while it is so easy to early check what could go wrong with it.
