linux-stable.git/drivers/net/macvtap.c, branch linux-3.14.y

macvtap: unbreak receiving of gro skb with frag list

2015-12-09T18:42:52+00:00

[ Upstream commit f23d538bc24a83c16127c2eb82c9cf1adc2b5149 ]

We don't have fraglist support in TAP_FEATURES. This will lead
software segmentation of gro skb with frag list. Fixes by having
frag list support in TAP_FEATURES.

With this patch single session of netperf receiving were restored from
about 5Gb/s to about 12Gb/s on mlx4.

Fixes a567dd6252 ("macvtap: simplify usage of tap_features")
Cc: Vlad Yasevich 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvtap: make sure neighbour code can push ethernet header

2015-03-18T12:31:22+00:00

[ Upstream commit 2f1d8b9e8afa5a833d96afcd23abcb8cdf8d83ab ]

Brian reported crashes using IPv6 traffic with macvtap/veth combo.

I tracked the crashes in neigh_hh_output()

-> memcpy(skb->data - HH_DATA_MOD, hh->hh_data, HH_DATA_MOD);

Neighbour code assumes headroom to push Ethernet header is
at least 16 bytes.

It appears macvtap has only 14 bytes available on arches
where NET_IP_ALIGN is 0 (like x86)

Effect is a corruption of 2 bytes right before skb->head,
and possible crashes if accessing non existing memory.

This fix should also increase IPv4 performance, as paranoid code
in ip_finish_output2() wont have to call skb_realloc_headroom()

Reported-by: Brian Rak 
Tested-by: Brian Rak 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvtap: Fix csum_start when VLAN tags are present

2014-11-21T17:23:01+00:00

commit 3ce9b20f1971690b8b3b620e735ec99431573b39 upstream.

When VLAN is in use in macvtap_put_user, we end up setting
csum_start to the wrong place.  The result is that the whoever
ends up doing the checksum setting will corrupt the packet instead
of writing the checksum to the expected location, usually this
means writing the checksum with an offset of -4.

This patch fixes this by adjusting csum_start when VLAN tags are
detected.

Fixes: f09e2249c4f5 ("macvtap: restore vlan header on user read")
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: David S. Miller

Revert "drivers/net: Disable UFO through virtio"

2014-11-21T17:22:59+00:00

This reverts commit 2b52d6c6beda6308ba95024a1eba1dfc9515ba32 which was
commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 upstream.

Ben writes:

	Please drop this patch for 3.14 and 3.17.  It causes problems
	for migration of VMs and we're probably going to revert part of
	this.  The following patch ("drivers/net, ipv6: Select IPv6
	fragment idents for virtio UFO packets") might no longer apply,
	in which case you can drop that as well until we have this
	sorted out upstream.

Cc: Ben Hutchings 
Cc: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets

2014-11-14T16:59:44+00:00

[ Upstream commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7 ]

UFO is now disabled on all drivers that work with virtio net headers,
but userland may try to send UFO/IPv6 packets anyway.  Instead of
sending with ID=0, we should select identifiers on their behalf (as we
used to).

Signed-off-by: Ben Hutchings 
Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

drivers/net: Disable UFO through virtio

2014-11-14T16:59:44+00:00

[ Upstream commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 ]

IPv6 does not allow fragmentation by routers, so there is no
fragmentation ID in the fixed header.  UFO for IPv6 requires the ID to
be passed separately, but there is no provision for this in the virtio
net protocol.

Until recently our software implementation of UFO/IPv6 generated a new
ID, but this was a bug.  Now we will use ID=0 for any UFO/IPv6 packet
passed through a tap, which is even worse.

Unfortunately there is no distinction between UFO/IPv4 and v6
features, so disable UFO on taps and virtio_net completely until we
have a proper solution.

We cannot depend on VM managers respecting the tap feature flags, so
keep accepting UFO packets but log a warning the first time we do
this.

Signed-off-by: Ben Hutchings 
Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvtap: Fix race between device delete and open.

2014-10-15T06:36:42+00:00

[ Upstream commit 40b8fe45d1f094e3babe7b2dc2b71557ab71401d ]

In macvtap device delete and open calls can race and
this causes a list curruption of the vlan queue_list.

The race intself is triggered by the idr accessors
that located the vlan device.  The device is stored
into and removed from the idr under both an rtnl and
a mutex.  However, when attempting to locate the device
in idr, only a mutex is taken.  As a result, once cpu
perfoming a delete may take an rtnl and wait for the mutex,
while another cput doing an open() will take the idr
mutex first to fetch the device pointer and later take
an rtnl to add a queue for the device which may have
just gotten deleted.

With this patch, we now hold the rtnl for the duration
of the macvtap_open() call thus making sure that
open will not race with delete.

CC: Michael S. Tsirkin 
CC: Jason Wang 
Signed-off-by: Vladislav Yasevich 
Acked-by: Jason Wang 
Acked-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

mactap: Fix checksum errors for non-gso packets in bridge mode

2014-05-31T20:20:36+00:00

[ Upstream commit cbdb04279ccaefcc702c8757757eea8ed76e50cf ]

The following is a problematic configuration:

 VM1: virtio-net device connected to macvtap0@eth0
 VM2: e1000 device connect to macvtap1@eth0

The problem is is that virtio-net supports checksum offloading
and thus sends the packets to the host with CHECKSUM_PARTIAL set.
On the other hand, e1000 does not support any acceleration.

For small TCP packets (and this includes the 3-way handshake),
e1000 ends up receiving packets that only have a partial checksum
set.  This causes TCP to fail checksum validation and to drop
packets.  As a result tcp connections can not be established.

Commit 3e4f8b787370978733ca6cae452720a4f0c296b8
	macvtap: Perform GSO on forwarding path.
fixes this issue for large packets wthat will end up undergoing GSO.
This commit adds a check for the non-GSO case and attempts to
compute the checksum for partially checksummed packets in the
non-GSO case.

CC: Daniel Lezcano 
CC: Patrick McHardy 
CC: Andrian Nord 
CC: Eric Dumazet 
CC: Michael S. Tsirkin 
CC: Jason Wang 
Signed-off-by: Vlad Yasevich 
Acked-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

drivers/net: delete non-required instances of include

2014-01-16T19:53:26+00:00

None of these files are actually using any __init type directives
and hence don't need to include .   Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.

This covers everything under drivers/net except for wireless, which
has been submitted separately.

Signed-off-by: Paul Gortmaker 
Signed-off-by: David S. Miller

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

2013-12-18T21:42:06+00:00

Conflicts:
	drivers/net/ethernet/intel/i40e/i40e_main.c
	drivers/net/macvtap.c

Both minor merge hassles, simple overlapping changes.

Signed-off-by: David S. Miller