[PATCH net-next] mlxsw: spectrum_router: Simplify VRF enslavement

From: Ido Schimmel When a netdev is enslaved to a VRF master, its router interface (RIF) needs to be destroyed (if exists) and a new one created using the corresponding virtual router (VR). >From the driver's perspective, the above is equivalent to an inetaddr event sent

[PATCH net v3 2/2] bridge: netlink: register netdevice before executing changelink

From: Ido Schimmel Peter reported a kernel oops when executing the following command: $ ip link add name test type bridge vlan_default_pvid 1 [13634.939408] BUG: unable to handle kernel NULL pointer dereference at 0190 [13634.939436] IP: __vlan_add+0x73/0x5f0

[PATCH net v3 0/2] bridge: Fix kernel oops during bridge creation

From: Ido Schimmel First patch adds a missing ndo_uninit() in the bridge driver, which is a prerequisite for the second patch that actually fixes the oops. Please consider both patches for 4.4.y, 4.9.y and 4.10.y Ido Schimmel (2): bridge: implement missing ndo_uninit()

[PATCH net v3 1/2] bridge: implement missing ndo_uninit()

From: Ido Schimmel While the bridge driver implements an ndo_init(), it was missing a symmetric ndo_uninit(), causing the different de-initialization operations to be scattered around its dellink() and destructor(). Implement a symmetric ndo_uninit() and remove the

[PATCH net v2 2/2] bridge: netlink: register netdevice before executing changelink

From: Ido Schimmel Peter reported a kernel oops when executing the following command: $ ip link add name test type bridge vlan_default_pvid 1 [13634.939408] BUG: unable to handle kernel NULL pointer dereference at 0190 [13634.939436] IP: __vlan_add+0x73/0x5f0

[PATCH net v2 0/2] bridge: Fix kernel oops during bridge creation

From: Ido Schimmel First patch adds a missing ndo_uninit() in the bridge driver, which is a prerequisite for the second patch that actually fixes the oops. First version was rejected for being "half baked", but given the amount of changes in this version and that three

[PATCH net v2 1/2] bridge: implement missing ndo_uninit()

From: Ido Schimmel While the bridge driver implements an ndo_init(), it was missing a symmetric ndo_uninit(), causing the different de-initialization operations to be scattered around its dellink() and destructor(). Implement a symmetric ndo_uninit() and remove the

[PATCH net] bridge: netlink: register netdevice before executing changelink

From: Ido Schimmel Peter reported a kernel oops when executing the following command: $ ip link add name test type bridge vlan_default_pvid 1 [13634.939408] BUG: unable to handle kernel NULL pointer dereference at 0190 [13634.939436] IP: __vlan_add+0x73/0x5f0

[PATCH net-next v2] ipv4: fib: Replay events when registering FIB notifier

From: Ido Schimmel When registering a FIB notifier block we should notify the caller of already existing FIB entries and rules, as it would otherwise have an incomplete view of the FIB tables. This is especially important for switchdev drivers that support FIB offloads.

[PATCH net-next] ipv4: fib: Replay events when registering FIB notifier

From: Ido Schimmel When registering a FIB notifier block we should notify the caller of already existing FIB entries and rules, as it would otherwise have an incomplete view of the FIB tables. This is especially important for switchdev drivers that support FIB offloads.

[PATCH net-next] switchdev: Remove redundant variable

From: Ido Schimmel Instead of storing return value in 'err' and returning, just return directly. Signed-off-by: Ido Schimmel Reviewed-by: Jiri Pirko --- net/switchdev/switchdev.c | 5 + 1 file changed, 1 insertion(+), 4

[PATCH net-next] net: core: Traverse the adjacency list from first entry

From: Ido Schimmel netdev_next_lower_dev() returns NULL when we finished traversing the adjacency list ('iter' points to the list's head). Therefore, we must start traversing the list from the first entry and not its head. Fixes: 1a3f060c1a47 ("net: Introduce new api for

[PATCH net] net: core: Correctly iterate over lower adjacency list

From: Ido Schimmel Tamir reported the following trace when processing ARP requests received via a vlan device on top of a VLAN-aware bridge: NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [swapper/1:0] [...] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW