linux-stable.git/drivers/net/vxlan.c, branch v3.14

vxlan: fix nonfunctional neigh_reduce()

2014-03-24T19:35:10+00:00

The VXLAN neigh_reduce() code is completely non-functional since
check-in. Specific errors:

1) The original code drops all packets with a multicast destination address,
	even though neighbor solicitations are sent to the solicited-node
	address, a multicast address. The code after this check was never run.
2) The neighbor table lookup used the IPv6 header destination, which is the
	solicited node address, rather than the target address from the
	neighbor solicitation. So neighbor lookups would always fail if it
	got this far. Also for L3MISSes.
3) The code calls ndisc_send_na(), which does a send on the tunnel device.
	The context for neigh_reduce() is the transmit path, vxlan_xmit(),
	where the host or a bridge-attached neighbor is trying to transmit
	a neighbor solicitation. To respond to it, the tunnel endpoint needs
	to do a *receive* of the appropriate neighbor advertisement. Doing a
	send, would only try to send the advertisement, encapsulated, to the
	remote destinations in the fdb -- hosts that definitely did not do the
	corresponding solicitation.
4) The code uses the tunnel endpoint IPv6 forwarding flag to determine the
	isrouter flag in the advertisement. This has nothing to do with whether
	or not the target is a router, and generally won't be set since the
	tunnel endpoint is bridging, not routing, traffic.

	The patch below creates a proxy neighbor advertisement to respond to
neighbor solicitions as intended, providing proper IPv6 support for neighbor
reduction.

Signed-off-by: David L Stevens 
Signed-off-by: David S. Miller

vxlan: fix potential NULL dereference in arp_reduce()

2014-03-18T20:09:34+00:00

This patch fixes a NULL pointer dereference in the event of an
skb allocation failure in arp_reduce().

Signed-Off-By: David L Stevens 
Acked-by: Cong Wang 

Signed-off-by: David S. Miller

vxlan: remove extra newline after function definition

2014-02-02T00:58:02+00:00

Signed-off-by: Daniel Baluta 
Signed-off-by: David S. Miller

net/vxlan: Go over all candidate streams for GRO matching

2014-01-31T00:25:49+00:00

The loop in vxlan_gro_receive() over the current set of candidates for
coalescing was wrongly aborted once a match was found. In rare cases,
this can cause a false-positives matching in the next layer GRO checks.

Signed-off-by: Or Gerlitz 
Signed-off-by: David S. Miller

net/vxlan: Share RX skb de-marking and checksum checks with ovs

2014-01-23T21:30:03+00:00

Make sure the practice set by commit 0afb166 "vxlan: Add capability
of Rx checksum offload for inner packet" is applied when the skb
goes through the portion of the RX code which is shared between
vxlan netdevices and ovs vxlan port instances.

Cc: Joseph Gasparakis 
Cc: Pravin B Shelar 
Signed-off-by: Or Gerlitz 
Signed-off-by: David S. Miller

net: vxlan: convert to act as a pernet subsystem

2014-01-23T01:43:38+00:00

As per suggestion from Eric W. Biederman, vxlan should be using
{un,}register_pernet_subsys() instead of {un,}register_pernet_device()
to ensure the vxlan_net structure is initialized before and cleaned
up after all network devices in a given network namespace i.e. when
dealing with network notifiers. This is similarly handeled already in
commit 91e2ff3528ac ("net: Teach vlans to cleanup as a pernet subsystem")
and, thus, improves upon fd27e0d44a89 ("net: vxlan: do not use vxlan_net
before checking event type"). Just as in 91e2ff3528ac, we do not need
to explicitly handle deletion of vxlan devices as network namespace
exit calls dellink on all remaining virtual devices, and
rtnl_link_unregister() calls dellink on all outstanding devices in that
network namespace, so we can entirely drop the pernet exit operation
as well. Moreover, on vxlan module exit, rcu_barrier() is called by
netns since commit 3a765edadb28 ("netns: Add an explicit rcu_barrier
to unregister_pernet_{device|subsys}"), so this may be omitted. Tested
with various scenarios and works well on my side.

Suggested-by: Eric W. Biederman 
Cc: Jesse Brandeburg 
Cc: Eric W. Biederman 
Signed-off-by: Daniel Borkmann 
Signed-off-by: David S. Miller

net: Add GRO support for vxlan traffic

2014-01-22T02:05:04+00:00

Add GRO handlers for vxlann, by using the UDP GRO infrastructure.

For single TCP session that goes through vxlan tunneling I got nice
improvement from 6.8Gbs to 11.5Gbs

--> UDP/VXLAN GRO disabled
$ netperf  -H 192.168.52.147 -c -C

$ netperf -t TCP_STREAM -H 192.168.52.147 -c -C
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.52.147 () port 0 AF_INET
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

 87380  65536  65536    10.00      6799.75   12.54    24.79    0.604   1.195

--> UDP/VXLAN GRO enabled

$ netperf -t TCP_STREAM -H 192.168.52.147 -c -C
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.52.147 () port 0 AF_INET
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

 87380  65536  65536    10.00      11562.72   24.90    20.34    0.706   0.577

Signed-off-by: Shlomo Pongratz 
Signed-off-by: Or Gerlitz 
Signed-off-by: David S. Miller

net: add vxlan description

2014-01-22T00:28:07+00:00

Add a description to the vxlan module, helping save the world
from the minions of destruction and confusion.

Signed-off-by: Jesse Brandeburg 
CC: Stephen Hemminger 
Signed-off-by: David S. Miller

net: vxlan: do not use vxlan_net before checking event type

2014-01-18T02:49:18+00:00

Jesse Brandeburg reported that commit acaf4e70997f caused a panic
when adding a network namespace while vxlan module was present in
the system:

[] vxlan_lowerdev_event+0xf5/0x100
[] notifier_call_chain+0x4d/0x70
[] __raw_notifier_call_chain+0xe/0x10
[] raw_notifier_call_chain+0x16/0x20
[] call_netdevice_notifiers_info+0x40/0x70
[] call_netdevice_notifiers+0x16/0x20
[] register_netdevice+0x1be/0x3a0
[] register_netdev+0x1e/0x30
[] loopback_net_init+0x4a/0xb0
[] ? lockd_init_net+0x6e/0xb0 [lockd]
[] ops_init+0x4c/0x150
[] setup_net+0x73/0x110
[] copy_net_ns+0x7b/0x100
[] create_new_namespaces+0x101/0x1b0
[] copy_namespaces+0x85/0xb0
[] copy_process.part.26+0x935/0x1500
[] ? mntput+0x26/0x40
[] do_fork+0xbc/0x2e0
[] ? ____fput+0xe/0x10
[] ? task_work_run+0xac/0xe0
[] SyS_clone+0x16/0x20
[] stub_clone+0x69/0x90
[] ? system_call_fastpath+0x16/0x1b

Apparently loopback device is being registered first and thus we
receive an event notification when vxlan_net is not ready. Hence,
when we call net_generic() and request vxlan_net_id, we seem to
access garbage at that point in time. In setup_net() where we set
up a newly allocated network namespace, we traverse the list of
pernet ops ...

list_for_each_entry(ops, &pernet_list, list) {
	error = ops_init(ops, net);
	if (error < 0)
		goto out_undo;
}

... and loopback_net_init() is invoked first here, so in the middle
of setup_net() we get this notification in vxlan. As currently we
only care about devices that unregister, move access through
net_generic() there. Fix is based on Cong Wang's proposal, but
only changes what is needed here. It sucks a bit as we only work
around the actual cure: right now it seems the only way to check if
a netns actually finished traversing all init ops would be to check
if it's part of net_namespace_list. But that I find quite expensive
each time we go through a notifier callback. Anyway, did a couple
of tests and it seems good for now.

Fixes: acaf4e70997f ("net: vxlan: when lower dev unregisters remove vxlan dev as well")
Reported-by: Jesse Brandeburg 
Cc: "Eric W. Biederman" 
Cc: Jesse Brandeburg 
Signed-off-by: Cong Wang 
Signed-off-by: Daniel Borkmann 
Tested-by: Jesse Brandeburg 
Signed-off-by: David S. Miller

net: vxlan: properly cleanup devs on module unload

2014-01-15T07:38:39+00:00

We should use vxlan_dellink() handler in vxlan_exit_net(), since
i) we're not in fast-path and we should be consistent in dismantle
just as we would remove a device through rtnl ops, and more
importantly, ii) in case future code will kfree() memory in
vxlan_dellink(), we would leak it right here unnoticed. Therefore,
do not only half of the cleanup work, but make it properly.

Signed-off-by: Daniel Borkmann 
Signed-off-by: David S. Miller