linux-stable.git/drivers/net/hyperv, branch linux-3.10.y

netvsc: reduce maximum GSO size

2017-06-20T12:03:26+00:00

commit a50af86dd49ee1851d1ccf06dd0019c05b95e297 upstream.

Hyper-V (and Azure) support using NVGRE which requires some extra space
for encapsulation headers. Because of this the largest allowed TSO
packet is reduced.

For older releases, hard code a fixed reduced value.  For next release,
there is a better solution which uses result of host offload
negotiation.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Willy Tarreau

hyperv: Fix a bug in netvsc_start_xmit()

2014-10-15T06:31:57+00:00

[ Upstream commit dedb845ded56ded1c62f5398a94ffa8615d4592d ]

After the packet is successfully sent, we should not touch the skb
as it may have been freed. This patch is based on the work done by
Long Li .

In this version of the patch I have fixed issues pointed out by David.
David, please queue this up for stable.

Signed-off-by: K. Y. Srinivasan 
Tested-by: Long Li 
Tested-by: Sitsofe Wheeler 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

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

2014-01-15T23:28:47+00:00

[ 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

hyperv: Fix the NETIF_F_SG flag setting in netvsc

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

[ Upstream commit f45708209dc445bac0844f6ce86e315a2ffe8a29 ]

SG mode is not currently supported by netvsc, so remove this flag for now.
Otherwise, it will be unconditionally enabled by commit ec5f0615642
    "Kill link between CSUM and SG features"
Previously, the SG feature is disabled because CSUM is not set here.

Signed-off-by: Haiyang Zhang 
Reviewed-by: K. Y. Srinivasan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Fix the VLAN_TAG_PRESENT in netvsc_recv_callback()

2013-06-17T22:58:11+00:00

We should call __vlan_hwaccel_put_tag() only if the packet
comes from vlan, otherwise VLAN_TAG_PRESENT will always be
added.

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

hyperv: Fix vlan_proto setting in netvsc_recv_callback()

2013-06-01T00:33:40+00:00

Since the recent addition of 8021AD, we need to set the new field vlan_proto in
sk_buff. Otherwise, it will trigger BUG() call in vlan_proto_idx().

This patch fixes the problem.

Signed-off-by: Haiyang Zhang 
Reviewed-by: K. Y. Srinivasan 
Signed-off-by: David S. Miller

hyperv: Fix a compiler warning in netvsc_send()

2013-04-29T18:06:32+00:00

Fixed: warning: cast from pointer to integer of different size

The Hyper-V hosts always use 64 bit request id. The guests can have 32 or 64
bit pointers which equal to the ulong type size. So we cast it to ulong type.
And, assigning 32bit integer to 64 bit variable works fine.

The VMBus returns the same id in the completion packet. But the value has no
effect on the host side.

Reported-by: kbuild test robot 
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

2013-04-23T00:32:51+00:00

Conflicts:
	drivers/net/ethernet/emulex/benet/be_main.c
	drivers/net/ethernet/intel/igb/igb_main.c
	drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
	include/net/scm.h
	net/batman-adv/routing.c
	net/ipv4/tcp_input.c

The e{uid,gid} --> {uid,gid} credentials fix conflicted with the
cleanup in net-next to now pass cred structs around.

The be2net driver had a bug fix in 'net' that overlapped with the VLAN
interface changes by Patrick McHardy in net-next.

An IGB conflict existed because in 'net' the build_skb() support was
reverted, and in 'net-next' there was a comment style fix within that
code.

Several batman-adv conflicts were resolved by making sure that all
calls to batadv_is_my_mac() are changed to have a new bat_priv first
argument.

Eric Dumazet's TS ECR fix in TCP in 'net' conflicted with the F-RTO
rewrite in 'net-next', mostly overlapping changes.

Thanks to Stephen Rothwell and Antonio Quartulli for help with several
of these merge resolutions.

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

hyperv: Fix RNDIS send_completion code path

2013-04-08T16:15:17+00:00

In some cases, the VM_PKT_COMP message can arrive later than RNDIS completion
message, which will free the packet memory. This may cause panic due to access
to freed memory in netvsc_send_completion().

This patch fixes this problem by removing rndis_filter_send_request_completion()
from the code path. The function was a no-op.

Reported-by: Long Li 
Tested-by: Long Li 
Signed-off-by: Haiyang Zhang 
Reviewed-by: K. Y. Srinivasan 
Signed-off-by: David S. Miller