linux/drivers/net/macvtap.c, branch v3.2.40

macvtap: zerocopy: validate vectors before building skb

2012-07-25T03:11:04Z

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 Signed-off-by: Ben Hutchings

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

2012-07-25T03:11:04Z

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 Signed-off-by: Ben Hutchings

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

2012-07-25T03:11:03Z

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 Signed-off-by: Ben Hutchings

macvtap: zerocopy: fix truesize underestimation

2012-07-25T03:11:03Z

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 Signed-off-by: Ben Hutchings

macvtap: zerocopy: fix offset calculation when building skb

2012-07-25T03:11:02Z

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 Signed-off-by: Ben Hutchings

macvtap: Fix the minor device number allocation

2011-10-21T06:53:07Z

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

macvtap: Rewrite macvtap_newlink so the error handling works.

2011-10-21T06:53:07Z

Place macvlan_common_newlink at the end of macvtap_newlink because failing in newlink after registering your network device is not supported. Move device_create into a netdevice creation notifier. The network device notifier is the only hook that is called after the network device has been registered with the device layer and before register_network_device returns success. Signed-off-by: Eric W. Biederman Signed-off-by: David S. Miller

macvtap: Don't leak unreceived packets when we delete a macvtap device.

2011-10-21T06:53:07Z

To avoid leaking packets in the receive queue. Add a socket destructor that will run whenever destroy a macvtap socket. Signed-off-by: Eric W. Biederman Signed-off-by: David S. Miller

macvtap: Fix macvtap_open races in the zero copy enable code.

2011-10-21T06:53:07Z

To see if it is appropriate to enable the macvtap zero copy feature don't test the lowerdev network device flags. Instead test the macvtap network device flags which are a direct copy of the lowerdev flags. This is important because nothing holds a reference to lowerdev and on a very bad day we lowerdev could be a pointer to stale memory. Signed-off-by: Eric W. Biederman Signed-off-by: David S. Miller

macvtap: Close a race between macvtap_open and macvtap_dellink.

2011-10-21T06:53:06Z

There is a small window in macvtap_open between looking up a networking device and calling macvtap_set_queue in which macvtap_del_queues called from macvtap_dellink. After calling macvtap_del_queues it is totally incorrect to allow macvtap_set_queue to proceed so prevent success by reporting that all of the available queues are in use. Signed-off-by: Eric W. Biederman Signed-off-by: David S. Miller