linux-stable.git/drivers/net/vxlan.c, branch v4.7.2

ovs/vxlan: fix rtnl notifications on iface deletion

2016-06-15T05:21:44+00:00

The function vxlan_dev_create() (only used by ovs) never calls
rtnl_configure_link(). The consequence is that dev->rtnl_link_state is
never set to RTNL_LINK_INITIALIZED.
During the deletion phase, the function rollback_registered_many() sends
a RTM_DELLINK only if dev->rtnl_link_state is set to RTNL_LINK_INITIALIZED.

Note that the function vxlan_dev_create() is moved after the rtnl stuff so
that vxlan_dellink() can be called in this function.

Fixes: dcc38c033b32 ("openvswitch: Re-add CONFIG_OPENVSWITCH_VXLAN")
CC: Thomas Graf 
CC: Pravin B Shelar 
Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller

vxlan: Accept user specified MTU value when create new vxlan link

2016-05-31T18:46:00+00:00

When create a new vxlan link, example:
  ip link add vtap mtu 1440 type vxlan vni 1 dev eth0

The argument "mtu" has no effect, because it is not set to conf->mtu. The
default value is used in vxlan_dev_configure function.

This problem was introduced by commit 0dfbdf4102b9 (vxlan: Factor out device
configuration).

Fixes: 0dfbdf4102b9 (vxlan: Factor out device configuration)
Signed-off-by:  Chen Haiquan 
Acked-by: Cong Wang 
Signed-off-by: David S. Miller

udp: prevent skbs lingering in tunnel socket queues

2016-05-20T23:56:02+00:00

In case we find a socket with encapsulation enabled we should call
the encap_recv function even if just a udp header without payload is
available. The callbacks are responsible for correctly verifying and
dropping the packets.

Also, in case the header validation fails for geneve and vxlan we
shouldn't put the skb back into the socket queue, no one will pick
them up there.  Instead we can simply discard them in the respective
encap_recv functions.

Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller

vxlan: set mac_header correctly in GPE mode

2016-05-16T17:37:10+00:00

For VXLAN-GPE, the interface is ARPHRD_NONE, thus we need to reset
mac_header after pulling the outer header.

v2: Put the code to the existing conditional block as suggested by
    Shmulik Ladkani.

Fixes: e1e5314de08b ("vxlan: implement GPE")
Signed-off-by: Jiri Benc 
Reviewed-by: Shmulik Ladkani 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2016-05-09T19:59:24+00:00

In netdevice.h we removed the structure in net-next that is being
changes in 'net'.  In macsec.c and rtnetlink.c we have overlaps
between fixes in 'net' and the u64 attribute changes in 'net-next'.

The mlx5 conflicts have to do with vxlan support dependencies.

Signed-off-by: David S. Miller

udp_offload: Set encapsulation before inner completes.

2016-05-06T22:25:26+00:00

UDP tunnel segmentation code relies on the inner offsets being set for
an UDP tunnel GSO packet, but the inner *_complete() functions will
set the inner offsets only if 'encapsulation' is set before calling
them.  Currently, udp_gro_complete() sets 'encapsulation' only after
the inner *_complete() functions are done.  This causes the inner
offsets having invalid values after udp_gro_complete() returns, which
in turn will make it impossible to properly segment the packet in case
it needs to be forwarded, which would be visible to the user either as
invalid packets being sent or as packet loss.

This patch fixes this by setting skb's 'encapsulation' in
udp_gro_complete() before calling into the inner complete functions,
and by making each possible UDP tunnel gro_complete() callback set the
inner_mac_header to the beginning of the tunnel payload.

Signed-off-by: Jarno Rajahalme 
Reviewed-by: Alexander Duyck 
Signed-off-by: David S. Miller

udp_tunnel: Remove redundant udp_tunnel_gro_complete().

2016-05-06T22:25:26+00:00

The setting of the UDP tunnel GSO type is already performed by
udp[46]_gro_complete().

Signed-off-by: Jarno Rajahalme 
Signed-off-by: David S. Miller

vxlan: fix initialization with custom link parameters

2016-04-29T19:08:56+00:00

Commit 0c867c9bf84c ("vxlan: move Ethernet initialization to a separate
function") changed initialization order and as an unintended result, when the
user specifies additional link parameters (such as IFLA_ADDRESS) while
creating vxlan interface, those are overwritten by vxlan_ether_setup later.

It's necessary to call ether_setup from withing the ->setup callback. That
way, the correct parameters are set by rtnl_create_link later. This is done
also for VXLAN-GPE, as we don't know the interface type yet at that point,
and changed to the correct interface type later.

Fixes: 0c867c9bf84c ("vxlan: move Ethernet initialization to a separate function")
Reported-by: Nicolas Dichtel 
Signed-off-by: Jiri Benc 
Tested-by: Nicolas Dichtel 
Signed-off-by: David S. Miller

vxlan: break dependency with netdev drivers

2016-04-21T19:35:44+00:00

Currently all drivers depend and autoload the vxlan module because how
vxlan_get_rx_port is linked into them. Remove this dependency:

By using a new event type in the netdevice notifier call chain we proxy
the request from the drivers to flush and resetup the vxlan ports not
directly via function call but by the already existing netdevice
notifier call chain.

I added a separate new event type, NETDEV_OFFLOAD_PUSH_VXLAN, to do so.
We don't need to save those ids, as the event type field is an unsigned
long and using specialized event types for this purpose seemed to be a
more elegant way. This also comes in beneficial if in future we want to
add offloading knobs for vxlan.

Cc: Jesse Gross 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller

ip_tunnel_core: iptunnel_handle_offloads returns int and doesn't free skb

2016-04-16T23:09:13+00:00

This patch updates the IP tunnel core function iptunnel_handle_offloads so
that we return an int and do not free the skb inside the function.  This
actually allows us to clean up several paths in several tunnels so that we
can free the skb at one point in the path without having to have a
secondary path if we are supporting tunnel offloads.

In addition it should resolve some double-free issues I have found in the
tunnels paths as I believe it is possible for us to end up triggering such
an event in the case of fou or gue.

Signed-off-by: Alexander Duyck 
Signed-off-by: David S. Miller