linux/drivers/net/hyperv, branch v3.4.80

netvsc: don't flush peers notifying work during setting mtu

2014-01-15T23:27:11Z

[ Upstream commit 50dc875f2e6e2e04aed3b3033eb0ac99192d6d02 ] There's a possible deadlock if we flush the peers notifying work during setting mtu: [ 22.991149] ====================================================== [ 22.991173] [ INFO: possible circular locking dependency detected ] [ 22.991198] 3.10.0-54.0.1.el7.x86_64.debug #1 Not tainted [ 22.991219] ------------------------------------------------------- [ 22.991243] ip/974 is trying to acquire lock: [ 22.991261] ((&(&net_device_ctx->dwork)->work)){+.+.+.}, at: [] flush_work+0x5/0x2e0 [ 22.991307] but task is already holding lock: [ 22.991330] (rtnl_mutex){+.+.+.}, at: [] rtnetlink_rcv+0x1b/0x40 [ 22.991367] which lock already depends on the new lock. [ 22.991398] the existing dependency chain (in reverse order) is: [ 22.991426] -> #1 (rtnl_mutex){+.+.+.}: [ 22.991449] [] __lock_acquire+0xb19/0x1260 [ 22.991477] [] lock_acquire+0xa2/0x1f0 [ 22.991501] [] mutex_lock_nested+0x89/0x4f0 [ 22.991529] [] rtnl_lock+0x17/0x20 [ 22.991552] [] netdev_notify_peers+0x12/0x30 [ 22.991579] [] netvsc_send_garp+0x22/0x30 [hv_netvsc] [ 22.991610] [] process_one_work+0x211/0x6e0 [ 22.991637] [] worker_thread+0x11b/0x3a0 [ 22.991663] [] kthread+0xed/0x100 [ 22.991686] [] ret_from_fork+0x7c/0xb0 [ 22.991715] -> #0 ((&(&net_device_ctx->dwork)->work)){+.+.+.}: [ 22.991715] [] check_prevs_add+0x967/0x970 [ 22.991715] [] __lock_acquire+0xb19/0x1260 [ 22.991715] [] lock_acquire+0xa2/0x1f0 [ 22.991715] [] flush_work+0x4e/0x2e0 [ 22.991715] [] __cancel_work_timer+0x95/0x130 [ 22.991715] [] cancel_delayed_work_sync+0x13/0x20 [ 22.991715] [] netvsc_change_mtu+0x84/0x200 [hv_netvsc] [ 22.991715] [] dev_set_mtu+0x34/0x80 [ 22.991715] [] do_setlink+0x23a/0xa00 [ 22.991715] [] rtnl_newlink+0x394/0x5e0 [ 22.991715] [] rtnetlink_rcv_msg+0x9c/0x260 [ 22.991715] [] netlink_rcv_skb+0xa9/0xc0 [ 22.991715] [] rtnetlink_rcv+0x2a/0x40 [ 22.991715] [] netlink_unicast+0xdd/0x190 [ 22.991715] [] netlink_sendmsg+0x337/0x750 [ 22.991715] [] sock_sendmsg+0x99/0xd0 [ 22.991715] [] ___sys_sendmsg+0x39e/0x3b0 [ 22.991715] [] __sys_sendmsg+0x42/0x80 [ 22.991715] [] SyS_sendmsg+0x12/0x20 [ 22.991715] [] system_call_fastpath+0x16/0x1b This is because we hold the rtnl_lock() before ndo_change_mtu() and try to flush the work in netvsc_change_mtu(), in the mean time, netdev_notify_peers() may be called from worker and also trying to hold the rtnl_lock. This will lead the flush won't succeed forever. Solve this by not canceling and flushing the work, this is safe because the transmission done by NETDEV_NOTIFY_PEERS was synchronized with the netif_tx_disable() called by netvsc_change_mtu(). Reported-by: Yaju Cao Tested-by: Yaju Cao Cc: K. Y. Srinivasan Cc: Haiyang Zhang Signed-off-by: Jason Wang Acked-by: Haiyang Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net/hyperv: Adding cancellation to ensure rndis filter is closed

2012-04-21T19:38:10Z

Although the network interface is down, the RX packets number which could be observed by ifconfig may keep on increasing. This is because the WORK scheduled in netvsc_set_multicast_list() may be executed after netvsc_close(). That means the rndis filter may be re-enabled by do_set_multicast() even if it was closed by netvsc_close(). By canceling possible WORK before close the rndis filter, the issue could be never happened. Signed-off-by: Wenqi Ma Reviewed-by: Wei Yongjun Signed-off-by: David S. Miller

net/hyperv: Fix the code handling tx busy

2012-03-19T21:27:06Z

Instead of dropping the packet, we keep the skb buffer, and return NETDEV_TX_BUSY to let upper layer retry send. This will not cause endless loop, because the host is taking data away from ring buffer, and we have called the stop_queue before returning NETDEV_TX_BUSY. The stop_queue was called in the function netvsc_send() in file netvsc.c, then it returns to rndis_filter_send(), which returns to netvsc_start_xmit() in file netvsc_drv.c. So the NETDEV_TX_BUSY is indeed returned AFTER queue is stopped. Signed-off-by: Haiyang Zhang Reviewed-by: K. Y. Srinivasan Acked-by: Eric Dumazet Signed-off-by: David S. Miller

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

2012-03-19T03:29:41Z

net/hyperv: fix erroneous NETDEV_TX_BUSY use

2012-03-16T09:01:17Z

A driver start_xmit() method cannot free skb and return NETDEV_TX_BUSY, since caller is going to reuse freed skb. This is mostly a revert of commit bf769375c (staging: hv: fix the return status of netvsc_start_xmit()) In fact netif_tx_stop_queue() / netif_stop_queue() is needed before returning NETDEV_TX_BUSY or you can trigger a ksoftirqd fatal loop. In case of memory allocation error, only safe way is to drop the packet and return NETDEV_TX_OK Signed-off-by: Eric Dumazet Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Greg Kroah-Hartman Reviewed-by: Haiyang Zhang Signed-off-by: David S. Miller

net/hyperv: Add support for vlan trunking from guests

2012-03-13T00:06:48Z

With this feature, a Linux guest can now configure multiple vlans through a single synthetic NIC on Win8 Hyper-V host. Signed-off-by: Haiyang Zhang Reviewed-by: K. Y. Srinivasan Signed-off-by: David S. Miller

net/hyperv: Fix data corruption in rndis_filter_receive()

2012-03-13T00:06:48Z

Limiting the memcpy to be the sizeof(struct rndis_message) can truncate the message if there are Per-Packet-Info or Out-of-Band data. In my earlier patch (commit 45326342), the unnecessary kmap_atomic and kunmap_atomic surrounding this memcpy have been removed because the memory in the receive buffer is always mapped. This memcpy is not necessary either. To fix the bug, I removed the memcpy. Signed-off-by: Haiyang Zhang Reviewed-by: K. Y. Srinivasan Signed-off-by: David S. Miller

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

2012-03-09T22:34:20Z

net/hyperv: Use the built-in macro KBUILD_MODNAME for this driver

2012-03-08T21:55:27Z

Signed-off-by: Haiyang Zhang Signed-off-by: K. Y. Srinivasan Cc: Olaf Hering Signed-off-by: David S. Miller

net/hyperv: Remove the unnecessary memset in rndis_filter_send()

2012-02-05T22:44:55Z

The memory has been allocated by kzalloc, so it's unnecessary to memset again. Signed-off-by: Haiyang Zhang Signed-off-by: K. Y. Srinivasan Signed-off-by: David S. Miller