1. 09 2月, 2012 1 次提交
    • J
      ixgbe: ethtool: stats user buffer overrun · 9cc00b51
      John Fastabend 提交于
      If the number of tx/rx queues changes the ethtool ioctl
      ETHTOOL_GSTATS may overrun the userspace buffer. This
      occurs because the general practice in user space to
      query stats is to issue a ETHTOOL_GSSET cmd to learn the
      buffer size needed, allocate the buffer, then call
      ETHTOOL_GSTIRNGS and ETHTOOL_GSTATS. If the number of
      real_num_queues is changed or flow control attributes
      are changed after ETHTOOL_GSSET but before the
      ETHTOOL_GSTRINGS/ETHTOOL_GSTATS a user space buffer
      overrun occurs.
      
      To fix the overrun always return the max buffer size
      needed from get_sset_count() then return all strings
      and stats from get_strings()/get_ethtool_stats().
      
      This _will_ change the output from the ioctl() call
      which could break applications and script parsing in
      theory. I believe these changes should not break existing
      tools because the only changes will be more {tx|rx}_queues
      and the {tx|rx}_pb_* stats will always be returned.
      Existing scripts already need to handle changing number
      of queues because this occurs today depending on system
      and current features. The {tx|rx}_pb_* stats are at the
      end of the output and should be handled by scripts today
      regardless.
      
      Finally get_ethtool_stats and get_strings are free-form
      outputs tools parsing these outputs should be defensive
      anyways. In the end these updates are better then
      having a tool segfault because of a buffer overrun.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      9cc00b51
  2. 03 2月, 2012 2 次提交
  3. 03 1月, 2012 1 次提交
  4. 15 11月, 2011 1 次提交
  5. 18 10月, 2011 1 次提交
  6. 17 10月, 2011 1 次提交
  7. 13 10月, 2011 1 次提交
  8. 08 10月, 2011 1 次提交
  9. 05 10月, 2011 2 次提交
    • M
      ixgbe: get pauseparam autoneg · 860502bf
      Mika Lansirinne 提交于
      There is a problem in the ixgbe driver with the reporting of the flow
      control parameters. The autoneg parameter is shown to be of if
      *either* it really is off, or current modes for both tx and rx are off.
      
      The problem is seen when the parameters are read or set when the link
      is down. In this case, the driver sees that tx and rx are currently off
      and therefore autoneg parameter is incorrectly reported to be off too.
      Also, the ethtool binary can not set the autoneg off since it sees that
      it already is. When a link later comes up, the autonegotiation is
      carried out normally and the driver later on reports the autoneg
      parameter to be on (as it is) and then it can also be changed with
      ethtool.
      
      The patch is made against v3.0 kernel, but the problem seems to be there
      since v2.6.30-rc1.
      
      Reviewer comments: What we are trying to do is to disable flow control
      while the cable is disconnected. Since ixgbe defaults to full flow
      control, we call ethtool -A autoneg off rx off tx off while the cable
      is disconnected. This doesn't work, because the driver sets
      hw->fc.current_mode = ixgbe_fc_none if the cable is unplugged.
      ixgbe_get_pauseparam() then reports to ethtool that nothing needs to be
      done. The code fixes this, but it might have some unknown consequences.
      Signed-off-by: NMika Lansirinne <mika.lansirinne@stonesoft.com>
      Reviewed-by: NEsa-Pekka Pyokkimies <esa-pekka.pyokkimies@stonesoft.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      860502bf
    • E
      ixgbe: send MFLCN to ethtool · 217995ec
      Emil Tantilov 提交于
      MFLCN register is used to set Rx flow control on parts newer than 82598.
      
      This patch sends the value of MFLCN to ethtool, so it can be used in a
      register dump (ethtool -d).
      Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com>
      Tested-by: NStephen Ko <stephen.s.ko@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      217995ec
  10. 29 9月, 2011 1 次提交
  11. 24 9月, 2011 1 次提交
  12. 17 9月, 2011 4 次提交
  13. 16 9月, 2011 1 次提交
  14. 29 8月, 2011 1 次提交
  15. 11 8月, 2011 1 次提交
  16. 04 8月, 2011 1 次提交
  17. 22 7月, 2011 3 次提交
  18. 24 6月, 2011 9 次提交
  19. 07 6月, 2011 1 次提交
  20. 15 5月, 2011 1 次提交
  21. 07 5月, 2011 2 次提交
  22. 05 5月, 2011 2 次提交
  23. 30 4月, 2011 1 次提交
    • D
      ethtool: cosmetic: Use ethtool ethtool_cmd_speed API · 70739497
      David Decotigny 提交于
      This updates the network drivers so that they don't access the
      ethtool_cmd::speed field directly, but use ethtool_cmd_speed()
      instead.
      
      For most of the drivers, these changes are purely cosmetic and don't
      fix any problem, such as for those 1GbE/10GbE drivers that indirectly
      call their own ethtool get_settings()/mii_ethtool_gset(). The changes
      are meant to enforce code consistency and provide robustness with
      future larger throughputs, at the expense of a few CPU cycles for each
      ethtool operation.
      
      All drivers compiled with make allyesconfig ion x86_64 have been
      updated.
      
      Tested: make allyesconfig on x86_64 + e1000e/bnx2x work
      Signed-off-by: NDavid Decotigny <decot@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      70739497