linux/drivers/net/ipvlan, branch v4.6

vlan: propagate gso_max_segs

2016-03-18T01:05:01Z

vlan drivers lack proper propagation of gso_max_segs from lower device. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller

net: ipvlan: use __ethtool_get_ksettings

2016-02-26T03:06:46Z

Signed-off-by: David Decotigny Signed-off-by: David S. Miller

ipvlan: misc changes

2016-02-22T03:43:24Z

1. scope correction for few functions that are used in single file. 2. Adjust variables that are used in fast-path to fit into single cacheline 3. Update rcv_frame() to skip shared check for frames coming over wire Signed-off-by: Mahesh Bandewar Signed-off-by: David S. Miller

ipvlan: mode is u16

2016-02-22T03:43:24Z

The mode argument was erronusly defined as u32 but it has always been u16. Also use ipvlan_set_mode() helper to set the mode instead of assigning directly. This should avoid future erronus assignments / updates. Signed-off-by: Mahesh Bandewar Signed-off-by: David S. Miller

ipvlan: scrub skb before routing in L3 mode.

2016-02-22T03:43:24Z

Scrub skb before hitting the iptable hooks to ensure packets hit these hooks. Set the xnet param only when the packet is crossing the ns boundry so if the IPvlan slave and master belong to the same ns, the param will be set to false. Signed-off-by: Mahesh Bandewar CC: Cong Wang Signed-off-by: David S. Miller

ipvlan: inherit MTU from master device

2016-02-05T00:18:53Z

When we create IPvlan slave; we use ether_setup() and that sets up default MTU to 1500 while the master device may have lower / different MTU. Any subsequent changes to the masters' MTU are reflected into the slaves' MTU setting. However if those don't happen (most likely scenario), the slaves' MTU stays at 1500 which could be bad. This change adds code to inherit MTU from the master device instead of using the default value during the link initialization phase. Signed-off-by: Mahesh Bandewar CC: Eric Dumazet CC: Tim Hockins Acked-by: Eric Dumazet Signed-off-by: David S. Miller

net: Rename NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK

2015-12-15T21:50:08Z

The name NETIF_F_ALL_CSUM is a misnomer. This does not correspond to the set of features for offloading all checksums. This is a mask of the checksum offload related features bits. It is incorrect to set both NETIF_F_HW_CSUM and NETIF_F_IP_CSUM or NETIF_F_IPV6 at the same time for features of a device. This patch: - Changes instances of NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK (where NETIF_F_ALL_CSUM is being used as a mask). - Changes bonding, sfc/efx, ipvlan, macvlan, vlan, and team drivers to use NEITF_F_HW_CSUM in features list instead of NETIF_F_ALL_CSUM. Signed-off-by: Tom Herbert Signed-off-by: David S. Miller

ipvlan: fix use after free of skb

2015-11-17T19:39:29Z

ipvlan_handle_frame is a rx_handler, and when it returns a value other than RX_HANDLER_CONSUMED (here, NET_RX_DROP aka RX_HANDLER_ANOTHER), __netif_receive_skb_core expects that the skb still exists and will process it further, but we just freed it. Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.") Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller

ipvlan: fix leak in ipvlan_rcv_frame

2015-11-17T19:39:28Z

Pass a **skb to ipvlan_rcv_frame so that if skb_share_check returns a new skb, we actually use it during further processing. It's safe to ignore the new skb in the ipvlan_xmit_* functions, because they call ipvlan_rcv_frame with local == true, so that dev_forward_skb is called and always takes ownership of the skb. Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.") Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller

ipvlan: read direct ifindex instead of iflink

2015-10-22T13:39:08Z

In the ipv4 outbound path of an ipvlan device in l3 mode, the ifindex is being grabbed from dev_get_iflink. This works for the physical device case, since as the documentation of that function notes: "Physical interfaces have the same 'ifindex' and 'iflink' values.". However, if the master device is a veth, and the pairs are in separate net namespaces, the route lookup will fail with -ENODEV due to outer veth pair being in a separate namespace from the ipvlan master/routing namespace. ns0 | ns1 | ns2 veth0a--|--veth0b--|--ipvl0 In ipvlan_process_v4_outbound(), a packet sent from ipvl0 in the above configuration will pass fl.flowi4_oif == veth0a to ip_route_output_flow(), but *net == ns1. Notice also that ipv6 processing is not using iflink. Since there is a discrepancy in usage, fixup both v4 and v6 case to use local dev variable. Tested this with l3 ipvlan on top of veth, as well as with single physical interface in the top namespace. Signed-off-by: Brenden Blanco Reviewed-by: Jiri Benc Acked-by: Mahesh Bandewar Signed-off-by: David S. Miller