1. 17 4月, 2019 1 次提交
  2. 10 3月, 2019 1 次提交
  3. 06 3月, 2019 2 次提交
  4. 14 11月, 2018 1 次提交
  5. 17 9月, 2018 1 次提交
  6. 14 9月, 2018 1 次提交
    • S
      hv_netvsc: fix schedule in RCU context · 018349d7
      Stephen Hemminger 提交于
      When netvsc device is removed it can call reschedule in RCU context.
      This happens because canceling the subchannel setup work could (in theory)
      cause a reschedule when manipulating the timer.
      
      To reproduce, run with lockdep enabled kernel and unbind
      a network device from hv_netvsc (via sysfs).
      
      [  160.682011] WARNING: suspicious RCU usage
      [  160.707466] 4.19.0-rc3-uio+ #2 Not tainted
      [  160.709937] -----------------------------
      [  160.712352] ./include/linux/rcupdate.h:302 Illegal context switch in RCU read-side critical section!
      [  160.723691]
      [  160.723691] other info that might help us debug this:
      [  160.723691]
      [  160.730955]
      [  160.730955] rcu_scheduler_active = 2, debug_locks = 1
      [  160.762813] 5 locks held by rebind-eth.sh/1812:
      [  160.766851]  #0: 000000008befa37a (sb_writers#6){.+.+}, at: vfs_write+0x184/0x1b0
      [  160.773416]  #1: 00000000b097f236 (&of->mutex){+.+.}, at: kernfs_fop_write+0xe2/0x1a0
      [  160.783766]  #2: 0000000041ee6889 (kn->count#3){++++}, at: kernfs_fop_write+0xeb/0x1a0
      [  160.787465]  #3: 0000000056d92a74 (&dev->mutex){....}, at: device_release_driver_internal+0x39/0x250
      [  160.816987]  #4: 0000000030f6031e (rcu_read_lock){....}, at: netvsc_remove+0x1e/0x250 [hv_netvsc]
      [  160.828629]
      [  160.828629] stack backtrace:
      [  160.831966] CPU: 1 PID: 1812 Comm: rebind-eth.sh Not tainted 4.19.0-rc3-uio+ #2
      [  160.832952] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012
      [  160.832952] Call Trace:
      [  160.832952]  dump_stack+0x85/0xcb
      [  160.832952]  ___might_sleep+0x1a3/0x240
      [  160.832952]  __flush_work+0x57/0x2e0
      [  160.832952]  ? __mutex_lock+0x83/0x990
      [  160.832952]  ? __kernfs_remove+0x24f/0x2e0
      [  160.832952]  ? __kernfs_remove+0x1b2/0x2e0
      [  160.832952]  ? mark_held_locks+0x50/0x80
      [  160.832952]  ? get_work_pool+0x90/0x90
      [  160.832952]  __cancel_work_timer+0x13c/0x1e0
      [  160.832952]  ? netvsc_remove+0x1e/0x250 [hv_netvsc]
      [  160.832952]  ? __lock_is_held+0x55/0x90
      [  160.832952]  netvsc_remove+0x9a/0x250 [hv_netvsc]
      [  160.832952]  vmbus_remove+0x26/0x30
      [  160.832952]  device_release_driver_internal+0x18a/0x250
      [  160.832952]  unbind_store+0xb4/0x180
      [  160.832952]  kernfs_fop_write+0x113/0x1a0
      [  160.832952]  __vfs_write+0x36/0x1a0
      [  160.832952]  ? rcu_read_lock_sched_held+0x6b/0x80
      [  160.832952]  ? rcu_sync_lockdep_assert+0x2e/0x60
      [  160.832952]  ? __sb_start_write+0x141/0x1a0
      [  160.832952]  ? vfs_write+0x184/0x1b0
      [  160.832952]  vfs_write+0xbe/0x1b0
      [  160.832952]  ksys_write+0x55/0xc0
      [  160.832952]  do_syscall_64+0x60/0x1b0
      [  160.832952]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [  160.832952] RIP: 0033:0x7fe48f4c8154
      
      Resolve this by getting RTNL earlier. This is safe because the subchannel
      work queue does trylock on RTNL and will detect the race.
      
      Fixes: 7b2ee50c ("hv_netvsc: common detach logic")
      Signed-off-by: NStephen Hemminger <sthemmin@microsoft.com>
      Reviewed-by: NHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      018349d7
  7. 01 9月, 2018 1 次提交
    • D
      hv_netvsc: Fix a deadlock by getting rtnl lock earlier in netvsc_probe() · e04e7a7b
      Dexuan Cui 提交于
      This patch fixes the race between netvsc_probe() and
      rndis_set_subchannel(), which can cause a deadlock.
      
      These are the related 3 paths which show the deadlock:
      
      path #1:
          Workqueue: hv_vmbus_con vmbus_onmessage_work [hv_vmbus]
          Call Trace:
           schedule
           schedule_preempt_disabled
           __mutex_lock
           __device_attach
           bus_probe_device
           device_add
           vmbus_device_register
           vmbus_onoffer
           vmbus_onmessage_work
           process_one_work
           worker_thread
           kthread
           ret_from_fork
      
      path #2:
          schedule
           schedule_preempt_disabled
           __mutex_lock
           netvsc_probe
           vmbus_probe
           really_probe
           __driver_attach
           bus_for_each_dev
           driver_attach_async
           async_run_entry_fn
           process_one_work
           worker_thread
           kthread
           ret_from_fork
      
      path #3:
          Workqueue: events netvsc_subchan_work [hv_netvsc]
          Call Trace:
           schedule
           rndis_set_subchannel
           netvsc_subchan_work
           process_one_work
           worker_thread
           kthread
           ret_from_fork
      
      Before path #1 finishes, path #2 can start to run, because just before
      the "bus_probe_device(dev);" in device_add() in path #1, there is a line
      "object_uevent(&dev->kobj, KOBJ_ADD);", so systemd-udevd can
      immediately try to load hv_netvsc and hence path #2 can start to run.
      
      Next, path #2 offloads the subchannal's initialization to a workqueue,
      i.e. path #3, so we can end up in a deadlock situation like this:
      
      Path #2 gets the device lock, and is trying to get the rtnl lock;
      Path #3 gets the rtnl lock and is waiting for all the subchannel messages
      to be processed;
      Path #1 is trying to get the device lock, but since #2 is not releasing
      the device lock, path #1 has to sleep; since the VMBus messages are
      processed one by one, this means the sub-channel messages can't be
      procedded, so #3 has to sleep with the rtnl lock held, and finally #2
      has to sleep... Now all the 3 paths are sleeping and we hit the deadlock.
      
      With the patch, we can make sure #2 gets both the device lock and the
      rtnl lock together, gets its job done, and releases the locks, so #1
      and #3 will not be blocked for ever.
      
      Fixes: 8195b139 ("hv_netvsc: fix deadlock on hotplug")
      Signed-off-by: NDexuan Cui <decui@microsoft.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e04e7a7b
  8. 22 8月, 2018 1 次提交
  9. 31 7月, 2018 1 次提交
    • Y
      hv_netvsc: Add per-cpu ethtool stats for netvsc · 6ae74671
      Yidong Ren 提交于
      This patch implements following ethtool stats fields for netvsc:
      cpu<n>_tx/rx_packets/bytes
      cpu<n>_vf_tx/rx_packets/bytes
      
      Corresponding per-cpu counters already exist in current code. Exposing
      these counters will help troubleshooting performance issues.
      
      for_each_present_cpu() was used instead of for_each_possible_cpu().
      for_each_possible_cpu() would create very long and useless output.
      It is still being used for internal buffer, but not for ethtool
      output.
      
      There could be an overflow if cpu was added between ethtool
      call netvsc_get_sset_count() and netvsc_get_ethtool_stats() and
      netvsc_get_strings(). (still safe if cpu was removed)
      ethtool makes these three function calls separately.
      As long as we use ethtool, I can't see any clean solution.
      
      Currently and in foreseeable short term, Hyper-V doesn't support
      cpu hot-plug. Plus, ethtool is for admin use. Unlikely the admin
      would perform such combo operations.
      
      Changes in v2:
        - Remove cpp style comment
        - Resubmit after freeze
      
      Changes in v3:
        - Reimplemented with kvmalloc instead of alloc_percpu
      
      Changes in v4:
        - Fixed inconsistent array size
        - Use kvmalloc_array instead of kvmalloc
      Signed-off-by: NYidong Ren <yidren@microsoft.com>
      Reviewed-by: NStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6ae74671
  10. 10 7月, 2018 2 次提交
  11. 03 7月, 2018 1 次提交
  12. 30 6月, 2018 1 次提交
  13. 13 6月, 2018 3 次提交
  14. 08 6月, 2018 1 次提交
    • D
      hv_netvsc: Fix a network regression after ifdown/ifup · 52acf73b
      Dexuan Cui 提交于
      Recently people reported the NIC stops working after
      "ifdown eth0; ifup eth0". It turns out in this case the TX queues are not
      enabled, after the refactoring of the common detach logic: when the NIC
      has sub-channels, usually we enable all the TX queues after all
      sub-channels are set up: see rndis_set_subchannel() ->
      netif_device_attach(), but in the case of "ifdown eth0; ifup eth0" where
      the number of channels doesn't change, we also must make sure the TX queues
      are enabled. The patch fixes the regression.
      
      Fixes: 7b2ee50c ("hv_netvsc: common detach logic")
      Signed-off-by: NDexuan Cui <decui@microsoft.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      52acf73b
  15. 03 6月, 2018 1 次提交
  16. 29 5月, 2018 1 次提交
  17. 24 5月, 2018 1 次提交
  18. 11 5月, 2018 1 次提交
  19. 19 4月, 2018 1 次提交
  20. 27 3月, 2018 1 次提交
  21. 26 3月, 2018 1 次提交
  22. 23 3月, 2018 1 次提交
    • S
      hv_netvsc: common detach logic · 7b2ee50c
      Stephen Hemminger 提交于
      Make common function for detaching internals of device
      during changes to MTU and RSS. Make sure no more packets
      are transmitted and all packets have been received before
      doing device teardown.
      
      Change the wait logic to be common and use usleep_range().
      
      Changes transmit enabling logic so that transmit queues are disabled
      during the period when lower device is being changed. And enabled
      only after sub channels are setup. This avoids issue where it could
      be that a packet was being sent while subchannel was not initialized.
      
      Fixes: 8195b139 ("hv_netvsc: fix deadlock on hotplug")
      Signed-off-by: NStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7b2ee50c
  23. 09 3月, 2018 2 次提交
  24. 05 3月, 2018 3 次提交
  25. 14 12月, 2017 5 次提交
  26. 03 12月, 2017 2 次提交
  27. 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
  28. 15 10月, 2017 1 次提交