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

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

2015-02-02T09:05:26+00:00

commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7 upstream.

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 
[bwh: For 3.2, net/ipv6/output_core.c is a completely new file]
Signed-off-by: Zefan Li

macvtap: Fix csum_start when VLAN tags are present

2015-02-02T09:05:18+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 

Cheers,
Signed-off-by: David S. Miller 
Signed-off-by: Zefan Li

macvtap: signal truncated packets

2014-01-15T23:27:10+00:00

[ Upstream commit ce232ce01d61b184202bb185103d119820e1260c ]

macvtap_put_user() never return a value grater than iov length, this in fact
bypasses the truncated checking in macvtap_recvmsg(). Fix this by always
returning the size of packet plus the possible vlan header to let the trunca
checking work.

Cc: Vlad Yasevich 
Cc: Zhi Yong Wu 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
Acked-by: Vlad Yasevich 
Acked-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvtap: update file current position

2014-01-15T23:27:10+00:00

[ Upstream commit e6ebc7f16ca1434a334647aa56399c546be4e64b ]

Signed-off-by: Zhi Yong Wu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvtap: Do not double-count received packets

2014-01-15T23:27:10+00:00

[ Upstream commit 006da7b07bc4d3a7ffabad17cf639eec6849c9dc ]

Currently macvlan will count received packets after calling each
vlans receive handler.   Macvtap attempts to count the packet
yet again when the user reads the packet from the tap socket.
This code doesn't do this consistently either.  Remove the
counting from macvtap and let only macvlan count received
packets.

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

macvtap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS

2013-09-14T13:02:11+00:00

commit ece793fcfc417b3925844be88a6a6dc82ae8f7c6 upstream.

We try to linearize part of the skb when the number of iov is greater than
MAX_SKB_FRAGS. This is not enough since each single vector may occupy more than
one pages, so zerocopy_sg_fromiovec() may still fail and may break the guest
network.

Solve this problem by calculate the pages needed for iov before trying to do
zerocopy and switch to use copy instead of zerocopy if it needs more than
MAX_SKB_FRAGS.

This is done through introducing a new helper to count the pages for iov, and
call uarg->callback() manually when switching from zerocopy to copy to notify
vhost.

We can do further optimization on top.

This bug were introduced from b92946e2919134ebe2a4083e4302236295ea2a73
(macvtap: zerocopy: validate vectors before building skb).

Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvtap: correctly linearize skb when zerocopy is used

2013-07-28T23:26:04+00:00

[ Upstream commit 61d46bf979d5cd7c164709a80ad5676a35494aae ]

Userspace may produce vectors greater than MAX_SKB_FRAGS. When we try to
linearize parts of the skb to let the rest of iov to be fit in
the frags, we need count copylen into linear when calling macvtap_alloc_skb()
instead of partly counting it into data_len. Since this breaks
zerocopy_sg_from_iovec() since its inner counter assumes nr_frags should
be zero at beginning. This cause nr_frags to be increased wrongly without
setting the correct frags.

This bug were introduced from b92946e2919134ebe2a4083e4302236295ea2a73
(macvtap: zerocopy: validate vectors before building skb).

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

macvtap: fix recovery from gup errors

2013-07-28T23:25:56+00:00

[ Upstream commit 4c7ab054ab4f5d63625508ed6f8a607184cae7c2 ]

get user pages might fail partially in macvtap zero copy
mode. To recover we need to put all pages that we got,
but code used a wrong index resulting in double-free
errors.

Reported-by: Brad Hubbard 
Signed-off-by: Michael S. Tsirkin 
Acked-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvtap: zerocopy: set SKBTX_DEV_ZEROCOPY only when skb is built successfully

2012-10-02T17:30:34+00:00

commit 01d6657b388438def19c8baaea28e742b6ed32ec upstream.

Current the SKBTX_DEV_ZEROCOPY is set unconditionally after
zerocopy_sg_from_iovec(), this would lead NULL pointer when macvtap
fails to build zerocopy skb because destructor_arg was not
initialized. Solve this by set this flag after the skb were built
successfully.

Signed-off-by: Jason Wang 
Signed-off-by: Michael S. Tsirkin 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

macvtap: zerocopy: put page when fail to get all requested user pages

2012-10-02T17:30:34+00:00

commit 02ce04bb3d28c3333231f43bca677228dbc686fe upstream.

When get_user_pages_fast() fails to get all requested pages, we could not use
kfree_skb() to free it as it has not been put in the skb fragments. So we need
to call put_page() instead.

Signed-off-by: Jason Wang 
Signed-off-by: Michael S. Tsirkin 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman