1. 08 9月, 2018 1 次提交
    • M
      r8169: set TxConfig register after TX / RX is enabled, just like RxConfig · f74dd480
      Maciej S. Szmigiero 提交于
      Commit 3559d81e ("r8169: simplify rtl_hw_start_8169") changed order of
      two register writes:
      1) Caused RxConfig to be written before TX / RX is enabled,
      2) Caused TxConfig to be written before TX / RX is enabled.
      
      At least on XIDs 10000000 ("RTL8169sb/8110sb") and
      18000000 ("RTL8169sc/8110sc") such writes are ignored by the chip, leaving
      values in these registers intact.
      
      Change 1) was reverted by
      commit 05212ba8 ("r8169: set RxConfig after tx/rx is enabled for RTL8169sb/8110sb devices"),
      however change 2) wasn't.
      
      In practice, this caused TxConfig's "InterFrameGap time" and "Max DMA Burst
      Size per Tx DMA Burst" bits to be zero dramatically reducing TX performance
      (in my tests it dropped from around 500Mbps to around 50Mbps).
      
      This patch fixes the issue by moving TxConfig register write a bit later in
      the code so it happens after TX / RX is already enabled.
      
      Fixes: 05212ba8 ("r8169: set RxConfig after tx/rx is enabled for RTL8169sb/8110sb devices")
      Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f74dd480
  2. 06 9月, 2018 10 次提交
  3. 05 9月, 2018 5 次提交
  4. 04 9月, 2018 5 次提交
  5. 03 9月, 2018 2 次提交
    • J
      net: cadence: Fix a sleep-in-atomic-context bug in macb_halt_tx() · 16fe10cf
      Jia-Ju Bai 提交于
      The kernel module may sleep with holding a spinlock.
      
      The function call paths (from bottom to top) in Linux-4.16 are:
      
      [FUNC] usleep_range
      drivers/net/ethernet/cadence/macb_main.c, 648:
      	usleep_range in macb_halt_tx
      drivers/net/ethernet/cadence/macb_main.c, 730:
      	macb_halt_tx in macb_tx_error_task
      drivers/net/ethernet/cadence/macb_main.c, 721:
      	_raw_spin_lock_irqsave in macb_tx_error_task
      
      To fix this bug, usleep_range() is replaced with udelay().
      
      This bug is found by my static analysis tool DSAC.
      Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      16fe10cf
    • T
      net: ethernet: cpsw-phy-sel: prefer phandle for phy sel · 18eb8aea
      Tony Lindgren 提交于
      The cpsw-phy-sel device is not a child of the cpsw interconnect target
      module. It lives in the system control module.
      
      Let's fix this issue by trying to use cpsw-phy-sel phandle first if it
      exists and if not fall back to current usage of trying to find the
      cpsw-phy-sel child. That way the phy sel driver can be a child of the
      system control module where it belongs in the device tree.
      
      Without this fix, we cannot have a proper interconnect target module
      hierarchy in device tree for things like genpd.
      
      Note that deferred probe is mostly not supported by cpsw and this patch
      does not attempt to fix that. In case deferred probe support is needed,
      this could be added to cpsw_slave_open() and phy_connect() so they start
      handling and returning errors.
      
      For documenting it, looks like the cpsw-phy-sel is used for all cpsw device
      tree nodes. It's missing the related binding documentation, so let's also
      update the binding documentation accordingly.
      
      Cc: devicetree@vger.kernel.org
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Murali Karicheri <m-karicheri2@ti.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      18eb8aea
  6. 01 9月, 2018 3 次提交
    • T
      ibmvnic: Include missing return code checks in reset function · f611a5b4
      Thomas Falcon 提交于
      Check the return codes of these functions and halt reset
      in case of failure. The driver will remain in a dormant state
      until the next reset event, when device initialization will be
      re-attempted.
      Signed-off-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f611a5b4
    • 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
    • J
      nfp: wait for posted reconfigs when disabling the device · 9ad716b9
      Jakub Kicinski 提交于
      To avoid leaking a running timer we need to wait for the
      posted reconfigs after netdev is unregistered.  In common
      case the process of deinitializing the device will perform
      synchronous reconfigs which wait for posted requests, but
      especially with VXLAN ports being actively added and removed
      there can be a race condition leaving a timer running after
      adapter structure is freed leading to a crash.
      
      Add an explicit flush after deregistering and for a good
      measure a warning to check if timer is running just before
      structures are freed.
      
      Fixes: 3d780b92 ("nfp: add async reconfiguration mechanism")
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9ad716b9
  7. 30 8月, 2018 8 次提交
  8. 28 8月, 2018 3 次提交
  9. 26 8月, 2018 3 次提交