1. 07 6月, 2017 30 次提交
  2. 06 6月, 2017 10 次提交
    • D
      Merge branch '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue · 25f41150
      David S. Miller 提交于
      Jeff Kirsher says:
      
      ====================
      1GbE Intel Wired LAN Driver Updates 2017-06-06
      
      This series contains updates and fixes to e1000e and igb.
      
      Matwey V Kornilov fixes an issue where igb_get_phy_id_82575() relies on
      the fact that page 0 is already selected, but this is not the case after
      igb_read_phy_reg_gs40g()/igb_write_phy_reg_gs40g() were removed in a
      previous commit.  This leads to initialization failure and some devices
      not working.  To fix the issue, explicitly select page 0 before first
      access to PHY registers.
      
      Arnd Bergmann modifies the driver to avoid a "defined but not used"
      warning by removing #ifdefs and using __maybe_unused annotation instead
      for new power management functions.
      
      Jake provides most of the changes in the series, all around PTP and
      timestamp fixes/updates.  Resolved several race conditions based on
      the hardware can only handle one transmit timestamp at a time, so
      fix the locking logic, as well as create a statistic for "skipped"
      timestamps to help administrators identify issues.
      
      Benjamin Poirier provides 2 changes, first to igb to remove the
      second argument to igb_update_stats() since it always passes the
      same two arguments.  So instead of having to pass the second argument,
      just update the function to the necessary information from the adapter
      structure.  Second modifies the e1000e_get_stats64() call to
      dev_get_stats() to avoid ethtool garbage being reported.
      
      Konstantin Khlebnikov modifies e1000e to use disable_hardirq(), instead
      of disable_irq() for MSIx vectors in e1000_netpoll().
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      25f41150
    • K
      e1000e: use disable_hardirq() also for MSIX vectors in e1000_netpoll() · fd8e597b
      Konstantin Khlebnikov 提交于
      Replace disable_irq() which waits for threaded irq handlers with
      disable_hardirq() which waits only for hardirq part.
      
      Fixes: 31119129 ("e1000: use disable_hardirq() for e1000_netpoll()")
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Acked-by: NCong Wang <xiyou.wangcong@gmail.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      fd8e597b
    • B
      e1000e: Don't return uninitialized stats · 24ad2a92
      Benjamin Poirier 提交于
      Some statistics passed to ethtool are garbage because e1000e_get_stats64()
      doesn't write them, for example: tx_heartbeat_errors. This leaks kernel
      memory to userspace and confuses users.
      
      Do like ixgbe and use dev_get_stats() which first zeroes out
      rtnl_link_stats64.
      
      Fixes: 5944701d ("net: remove useless memset's in drivers get_stats64")
      Reported-by: NStefan Priebe <s.priebe@profihost.ag>
      Signed-off-by: NBenjamin Poirier <bpoirier@suse.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      24ad2a92
    • B
      igb: Remove useless argument · 81e3f64a
      Benjamin Poirier 提交于
      Given that all callers of igb_update_stats() pass the same two arguments:
      (adapter, &adapter->stats64), the second argument can be removed.
      Signed-off-by: NBenjamin Poirier <bpoirier@suse.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      81e3f64a
    • J
      igb: check for Tx timestamp timeouts during watchdog · e5f36ad1
      Jacob Keller 提交于
      The igb driver has logic to handle only one Tx timestamp at a time,
      using a state bit lock to avoid multiple requests at once.
      
      It may be possible, if incredibly unlikely, that a Tx timestamp event is
      requested but never completes. Since we use an interrupt scheme to
      determine when the Tx timestamp occurred we would never clear the state
      bit in this case.
      
      Add an igb_ptp_tx_hang() function similar to the already existing
      igb_ptp_rx_hang() function. This function runs in the watchdog routine
      and makes sure we eventually recover from this case instead of
      permanently disabling Tx timestamps.
      
      Note: there is no currently known way to cause this without hacking the
      driver code to force it.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e5f36ad1
    • J
      igb: add statistic indicating number of skipped Tx timestamps · c3b8f85e
      Jacob Keller 提交于
      The igb driver can only handle one Tx timestamp request at a time.
      This means it is possible for an application timestamp request to be
      ignored.
      
      There is no easy way for an administrator to determine if this occurred.
      Add a new statistic which tracks this, tx_hwtstamp_skipped.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c3b8f85e
    • J
      e1000e: add statistic indicating number of skipped Tx timestamps · cff57141
      Jacob Keller 提交于
      The e1000e driver can only handle one Tx timestamp request at a time.
      This means it is possible for an application timestamp request to be
      ignored.
      
      There is no easy way for an administrator to determine if this occurred.
      Add a new statistic which tracks this, tx_hwtstamp_skipped.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      cff57141
    • J
      igb: avoid permanent lock of *_PTP_TX_IN_PROGRESS · 74344e32
      Jacob Keller 提交于
      The igb driver uses a state bit lock to avoid handling more than one Tx
      timestamp request at once. This is required because hardware is limited
      to a single set of registers for Tx timestamps.
      
      The state bit lock is not properly cleaned up during
      igb_xmit_frame_ring() if the transmit fails such as due to DMA or TSO
      failure. In some hardware this results in blocking timestamps until the
      service task times out. In other hardware this results in a permanent
      lock of the timestamp bit because we never receive an interrupt
      indicating the timestamp occurred, since indeed the packet was never
      transmitted.
      
      Fix this by checking for DMA and TSO errors in igb_xmit_frame_ring() and
      properly cleaning up after ourselves when these occur.
      Reported-by: NReported-by: David Mirabito <davidm@metamako.com>
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      74344e32
    • J
      igb: fix race condition with PTP_TX_IN_PROGRESS bits · 4ccdc013
      Jacob Keller 提交于
      Hardware related to the igb driver has a limitation of only handling one
      Tx timestamp at a time. Thus, the driver uses a state bit lock to
      enforce that only one timestamp request is honored at a time.
      
      Unfortunately this suffers from a simple race condition. The bit lock is
      not cleared until after skb_tstamp_tx() is called notifying the stack of
      a new Tx timestamp. Even a well behaved application which sends only one
      timestamp request at once and waits for a response might wake up and
      send a new packet before the bit lock is cleared. This results in
      needlessly dropping some Tx timestamp requests.
      
      We can fix this by unlocking the state bit as soon as we read the
      Timestamp register, as this is the first point at which it is safe to
      unlock.
      
      To avoid issues with the skb pointer, we'll use a copy of the pointer
      and set the global variable in the driver structure to NULL first. This
      ensures that the next timestamp request does not modify our local copy
      of the skb pointer.
      
      This ensures that well behaved applications do not accidentally race
      with the unlock bit. Obviously an application which sends multiple Tx
      timestamp requests at once will still only timestamp one packet at
      a time. Unfortunately there is nothing we can do about this.
      Reported-by: NDavid Mirabito <davidm@metamako.com>
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4ccdc013
    • J
      e1000e: fix race condition around skb_tstamp_tx() · 5012863b
      Jacob Keller 提交于
      The e1000e driver and related hardware has a limitation on Tx PTP
      packets which requires we limit to timestamping a single packet at once.
      We do this by verifying that we never request a new Tx timestamp while
      we still have a tx_hwtstamp_skb pointer.
      
      Unfortunately the driver suffers from a race condition around this. The
      tx_hwtstamp_skb pointer is not set to NULL until after skb_tstamp_tx()
      is called. This function notifies the stack and applications of a new
      timestamp. Even a well behaved application that only sends a new request
      when the first one is finished might be woken up and possibly send
      a packet before we can free the timestamp in the driver again. The
      result is that we needlessly ignore some Tx timestamp requests in this
      corner case.
      
      Fix this by assigning the tx_hwtstamp_skb pointer prior to calling
      skb_tstamp_tx() and use a temporary pointer to hold the timestamped skb
      until that function finishes. This ensures that the application is not
      woken up until the driver is ready to begin timestamping a new packet.
      
      This ensures that well behaved applications do not accidentally race
      with condition to skip Tx timestamps. Obviously an application which
      sends multiple Tx timestamp requests at once will still only timestamp
      one packet at a time. Unfortunately there is nothing we can do about
      this.
      Reported-by: NDavid Mirabito <davidm@metamako.com>
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      5012863b