kernel/linux.git/drivers/net/macvtap.c, branch v3.4.52

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

macvtap: zerocopy: fix truesize underestimation

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

commit 4ef67ebedffa44ed9939b34708ac2fee06d2f65f upstream. As the skb fragment were pinned/built from user pages, we should account the page instead of length for truesize. Signed-off-by: Jason Wang Signed-off-by: Michael S. Tsirkin Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

macvtap: zerocopy: fix offset calculation when building skb

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

commit 3afc9621f15701c557e60f61eba9242bac2771dd upstream. This patch fixes the offset calculation when building skb: - offset1 were used as skb data offset not vector offset - reset offset to zero only when we advance to next vector Signed-off-by: Jason Wang Signed-off-by: Michael S. Tsirkin Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

macvtap: zerocopy: validate vectors before building skb

2012-07-16T16:04:42+00:00

commit b92946e2919134ebe2a4083e4302236295ea2a73 upstream. There're several reasons that the vectors need to be validated: - Return error when caller provides vectors whose num is greater than UIO_MAXIOV. - Linearize part of skb when userspace provides vectors grater than MAX_SKB_FRAGS. - Return error when userspace provides vectors whose total length may exceed - MAX_SKB_FRAGS * PAGE_SIZE. Signed-off-by: Jason Wang Signed-off-by: Michael S. Tsirkin Cc: Josh Boyer Signed-off-by: Greg Kroah-Hartman

macvtap: restore vlan header on user read

2012-05-11T22:16:57+00:00

Ethernet vlan header is not on the packet and kept in the skb->vlan_tci when it comes from lower dev. This patch inserts vlan header in user buffer during skb copy on user read. Signed-off-by: Basil Gor Acked-by: Michael S. Tsirkin Signed-off-by: David S. Miller

security: trim security.h

2012-02-13T23:45:42+00:00

Trim security.h Signed-off-by: Al Viro Signed-off-by: James Morris

macvtap: Fix macvtap_get_queue to use rxhash first

2011-12-20T18:45:55+00:00

It was reported that the macvtap device selects a Acked-by: Michael S. Tsirkin Signed-off-by: David S. Miller

net: treewide use of RCU_INIT_POINTER

2011-11-23T23:48:19+00:00

rcu_assign_pointer(ptr, NULL) can be safely replaced by RCU_INIT_POINTER(ptr, NULL) (old rcu_assign_pointer() macro was testing the NULL value and could omit the smp_wmb(), but this had to be removed because of compiler warnings) Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller

macvtap: Fix the minor device number allocation

2011-10-21T06:53:07+00:00

On systems that create and delete lots of dynamic devices the 31bit linux ifindex fails to fit in the 16bit macvtap minor, resulting in unusable macvtap devices. I have systems running automated tests that that hit this condition in just a few days. Use a linux idr allocator to track which mavtap minor numbers are available and and to track the association between macvtap minor numbers and macvtap network devices. Remove the unnecessary unneccessary check to see if the network device we have found is indeed a macvtap device. With macvtap specific data structures it is impossible to find any other kind of networking device. Increase the macvtap minor range from 65536 to the full 20 bits that is supported by linux device numbers. It doesn't solve the original problem but there is no penalty for a larger minor device range. Signed-off-by: Eric W. Biederman Signed-off-by: David S. Miller