Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 09 3月, 2018 2 次提交
  3. 05 3月, 2018 3 次提交
  5. 14 12月, 2017 5 次提交
  7. 03 12月, 2017 2 次提交
  9. 16 11月, 2017 1 次提交
    • V
      hv_netvsc: preserve hw_features on mtu/channels/ringparam changes · aefd80e8
      由 Vitaly Kuznetsov 提交于 
      rndis_filter_device_add() is called both from netvsc_probe() when we
initially create the device and from set channels/mtu/ringparam
routines where we basically remove the device and add it back.

hw_features is reset in rndis_filter_device_add() and filled with
host data. However, we lose all additional flags which are set outside
of the driver, e.g. register_netdevice() adds NETIF_F_SOFT_FEATURES and
many others.

Unfortunately, calls to rndis_{query_hwcaps(), _set_offload_params()}
calls cannot be avoided on every RNDIS reset: host expects us to set
required features explicitly. Moreover, in theory hardware capabilities
can change and we need to reflect the change in hw_features.

Reset net->hw_features bits according to host data in
rndis_netdev_set_hwcaps(), clear corresponding feature bits
from net->features in case some features went missing (will never happen
in real life I guess but let's be consistent).
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NHaiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aefd80e8
  11. 15 10月, 2017 2 次提交
  13. 09 10月, 2017 2 次提交
  15. 05 10月, 2017 1 次提交
  17. 01 10月, 2017 1 次提交
  19. 26 9月, 2017 1 次提交
  21. 22 9月, 2017 1 次提交
    • A
      hv_netvsc: fix send buffer failure on MTU change · 0ab09bef
      由 Alex Ng 提交于 
      If MTU is changed the host would reject the send buffer change.
This problem is result of recent change to allow changing send
buffer size.

Every time we change the MTU, we store the previous net_device section
count before destroying the buffer, but we don’t store the previous
section size. When we reinitialize the buffer, its size is calculated
by multiplying the previous count and previous size. Since we
continuously increase the MTU, the host returns us a decreasing count
value while the section size is reinitialized to 1728 bytes every
time.

This eventually leads to a condition where the calculated buf_size is
so small that the host rejects it.

Fixes: 8b532797 ("netvsc: allow controlling send/recv buffer size")
Signed-off-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NStephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0ab09bef
  23. 16 9月, 2017 1 次提交
  25. 12 9月, 2017 1 次提交
    • S
      hv_netvsc: fix deadlock on hotplug · 8195b139
      由 Stephen Hemminger 提交于 
      When a virtual device is added dynamically (via host console), then
the vmbus sends an offer message for the primary channel. The processing
of this message for networking causes the network device to then
initialize the sub channels.

The problem is that setting up the sub channels needs to wait until
the subsequent subchannel offers have been processed. These offers
come in on the same ring buffer and work queue as where the primary
offer is being processed; leading to a deadlock.

This did not happen in older kernels, because the sub channel waiting
logic was broken (it wasn't really waiting).

The solution is to do the sub channel setup in its own work queue
context that is scheduled by the primary channel setup; and then
happens later.

Fixes: 732e4985 ("netvsc: fix race on sub channel creation")
Reported-by: NDexuan Cui <decui@microsoft.com>
Signed-off-by: NStephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8195b139
  27. 02 9月, 2017 5 次提交
  29. 25 8月, 2017 2 次提交
  31. 23 8月, 2017 3 次提交
  33. 12 8月, 2017 7 次提交