linux-stable.git/drivers/net/veth.c, branch linux-3.12.y

veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

2016-01-28T08:41:33+00:00

[ Upstream commit ce8c839b74e3017996fad4e1b7ba2e2625ede82f ]

Packets that arrive from real hardware devices have ip_summed ==
CHECKSUM_UNNECESSARY if the hardware verified the checksums, or
CHECKSUM_NONE if the packet is bad or it was unable to verify it. The
current version of veth will replace CHECKSUM_NONE with
CHECKSUM_UNNECESSARY, which causes corrupt packets routed from hardware to
a veth device to be delivered to the application. This caused applications
at Twitter to receive corrupt data when network hardware was corrupting
packets.

We believe this was added as an optimization to skip computing and
verifying checksums for communication between containers. However, locally
generated packets have ip_summed == CHECKSUM_PARTIAL, so the code as
written does nothing for them. As far as we can tell, after removing this
code, these packets are transmitted from one stack to another unmodified
(tcpdump shows invalid checksums on both sides, as expected), and they are
delivered correctly to applications. We didn’t test every possible network
configuration, but we tried a few common ones such as bridging containers,
using NAT between the host and a container, and routing from hardware
devices to containers. We have effectively deployed this in production at
Twitter (by disabling RX checksum offloading on veth devices).

This code dates back to the first version of the driver, commit
 ("[NET]: Virtual ethernet device driver"), so I
suspect this bug occurred mostly because the driver API has evolved
significantly since then. Commit <0b7967503dc97864f283a> ("net/veth: Fix
packet checksumming") (in December 2010) fixed this for packets that get
created locally and sent to hardware devices, by not changing
CHECKSUM_PARTIAL. However, the same issue still occurs for packets coming
in from hardware devices.

Co-authored-by: Evan Jones 
Signed-off-by: Evan Jones 
Cc: Nicolas Dichtel 
Cc: Phil Sutter 
Cc: Toshiaki Makita 
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Vijay Pandurangan 
Acked-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

veth: Fix vlan_features so as to be able to use stacked vlan interfaces

2014-03-13T22:19:38+00:00

[ Upstream commit 8d0d21f4053c07714802cbe8b1fe26913ec296cc ]

Even if we create a stacked vlan interface such as veth0.10.20, it sends
single tagged frames (tagged with only vid 10).
Because vlan_features of a veth interface has the
NETIF_F_HW_VLAN_[CTAG/STAG]_TX bits, veth0.10 also has that feature, so
dev_hard_start_xmit(veth0.10) doesn't call __vlan_put_tag() and
vlan_dev_hard_start_xmit(veth0.10) overwrites vlan_tci.
This prevents us from using a combination of 802.1ad and 802.1Q
in containers, etc.

Signed-off-by: Toshiaki Makita 
Acked-by: Flavio Leitner 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

veth: add vlan features

2013-07-20T00:36:03+00:00

The veth device doesn't provide the vlan features,
so TSO for example is disabled and that causes
performance issues when using tagged traffic.

The test topology looks like this:

    br0                     br1
  /   \                  /     \
vnet  veth0.10 ----- veth1.10   vnet
VM                               VM

The netperf results with current veth driver:
MIGRATED TCP STREAM TEST from 192.168.1.1 ()
port 0 AF_INET to 192.168.1.2 () port 0 AF_INET
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    10.01    2210.22

Now after applying the proposed patch:
MIGRATED TCP STREAM TEST from 192.168.1.1 ()
port 0 AF_INET to 192.168.1.2 () port 0 AF_INET
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    10.00    13067.47

Signed-off-by: Flavio Leitner 
Signed-off-by: David S. Miller

veth: remove redundant call of dev_alloc_name

2013-06-12T08:21:20+00:00

it's called in the following register_netdevice. No need to call it
here.
Tested with "ip link add type veth" and "ip link add xxx%d type veth".

Signed-off-by: Hong Zhiguo 
Signed-off-by: David S. Miller

net: vlan: announce STAG offload capability in some drivers

2013-04-19T18:46:06+00:00

- macvlan: propagate STAG filtering capabilities from underlying device
- ifb: announce STAG tagging support in addition to CTAG tagging support
- veth: announce STAG tagging/stripping support in addition to CTAG support

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

net: vlan: rename NETIF_F_HW_VLAN_* feature flags to NETIF_F_HW_VLAN_CTAG_*

2013-04-19T18:45:26+00:00

Rename the hardware VLAN acceleration features to include "CTAG" to indicate
that they only support CTAGs. Follow up patches will introduce 802.1ad
server provider tagging (STAGs) and require the distinction for hardware not
supporting acclerating both.

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

veth: fix NULL dereference in veth_dellink()

2013-02-11T01:41:43+00:00

commit d0e2c55e7c940 (veth: avoid a NULL deref in veth_stats_one)
added another NULL deref in veth_dellink().

# ip link add name veth1 type veth peer name veth0
# rmmod veth

We crash because veth_dellink() is called twice, so we must
take care of NULL peer.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

veth: fix a NULL deref in netif_carrier_off

2013-01-10T22:11:46+00:00

In commit d0e2c55e7c94 (veth: avoid a NULL deref in veth_stats_one)
we now clear the peer pointers in veth_dellink()

veth_close() must therefore make sure the peer pointer is set.

Reported-by: Tom Parkin 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

veth: avoid a NULL deref in veth_stats_one

2013-01-08T03:42:50+00:00

commit 2681128f0ced8a (veth: extend device features) added a NULL deref
in veth_stats_one(), as veth_get_stats64() was not testing if the peer
device was setup or not.

At init time, we call dev_get_stats() before veth pair is fully setup.

[  178.854758]  [] veth_get_stats64+0x47/0x70 [veth]
[  178.861013]  [] dev_get_stats+0x6d/0x130
[  178.866486]  [] rtnl_fill_ifinfo+0x47c/0x930
[  178.872299]  [] rtmsg_ifinfo+0x83/0x100
[  178.877678]  [] rtnl_configure_link+0x76/0xa0
[  178.883580]  [] veth_newlink+0x16a/0x350 [veth]
[  178.889654]  [] rtnl_newlink+0x4dc/0x5e0
[  178.895128]  [] ? rtnl_newlink+0x12e/0x5e0
[  178.900769]  [] rtnetlink_rcv_msg+0x11d/0x310
[  178.906669]  [] ? __rtnl_unlock+0x20/0x20
[  178.912225]  [] netlink_rcv_skb+0xa9/0xd0
[  178.917779]  [] rtnetlink_rcv+0x25/0x40
[  178.923159]  [] netlink_unicast+0x1b1/0x230
[  178.928887]  [] netlink_sendmsg+0x2fe/0x3b0
[  178.934615]  [] sock_sendmsg+0xd2/0xf0

So we must check if peer was setup in veth_get_stats64()

As pointed out by Ben Hutchings, priv->peer is missing proper
synchronization. Adding RCU protection is a safe and well documented
way to make sure we don't access about to be freed or already
freed data.

Reported-by: Tom Parkin 
Signed-off-by: Eric Dumazet 
CC: Ben Hutchings 
Signed-off-by: David S. Miller

veth: extend device features

2012-12-30T10:31:59+00:00

veth is lacking most modern facilities, like SG, checksums, TSO.

It makes sense to extend dev->features to get them, or GRO aggregation
is defeated by a forced segmentation.

Reported-by: Andrew Vagin 
Signed-off-by: Eric Dumazet 
Cc: Michał Mirosław 
Signed-off-by: David S. Miller