1. 18 12月, 2018 4 次提交
  2. 16 11月, 2018 2 次提交
  3. 16 10月, 2018 3 次提交
  4. 14 8月, 2018 2 次提交
    • A
      bnxt_en: take coredump_record structure off stack · 1bbf3aed
      Arnd Bergmann 提交于
      The bnxt_coredump_record structure is very long, causing a warning
      about possible stack overflow on 32-bit architectures:
      
      drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c: In function 'bnxt_get_coredump':
      drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c:2989:1: error: the frame size of 1188 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      
      I could not see any reason to operate on an on-stack copy of the
      structure before copying it back into the caller-provided buffer, which
      also simplifies the code here.
      
      Fixes: 6c5657d0 ("bnxt_en: Add support for ethtool get dump.")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1bbf3aed
    • A
      bnxt_en: avoid string overflow for record->system_name · 3d46eee5
      Arnd Bergmann 提交于
      The utsname()->nodename string may be 64 bytes long, and it gets
      copied without the trailing nul byte into the shorter record->system_name,
      as gcc now warns:
      
      In file included from include/linux/bitmap.h:9,
                       from include/linux/ethtool.h:16,
                       from drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c:13:
      In function 'strncpy',
          inlined from 'bnxt_fill_coredump_record' at drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c:2863:2:
      include/linux/string.h:254:9: error: '__builtin_strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
      
      Using strlcpy() at least avoids overflowing the destination buffer
      and adds proper nul-termination. It may still truncate long names
      though, which probably can't be solved here.
      
      Fixes: 6c5657d0 ("bnxt_en: Add support for ethtool get dump.")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d46eee5
  5. 11 8月, 2018 1 次提交
  6. 06 8月, 2018 5 次提交
  7. 08 5月, 2018 1 次提交
  8. 28 4月, 2018 3 次提交
  9. 20 4月, 2018 1 次提交
  10. 12 4月, 2018 1 次提交
  11. 01 4月, 2018 4 次提交
  12. 11 1月, 2018 1 次提交
  13. 02 12月, 2017 1 次提交
  14. 28 11月, 2017 1 次提交
  15. 03 11月, 2017 1 次提交
  16. 27 10月, 2017 4 次提交
  17. 15 10月, 2017 2 次提交
  18. 29 8月, 2017 1 次提交
    • M
      bnxt_en: Improve tx ring reservation logic. · 98fdbe73
      Michael Chan 提交于
      When the number of TX rings is changed (e.g. ethtool -L, enabling XDP TX
      rings, etc), the current code tries to reserve the new number of TX rings
      before closing and re-opening the NIC.  If we are unable to reserve the
      new TX rings, we abort the operation and keep the current TX rings.
      
      The problem is that the firmware will disable the current TX rings even
      when it cannot reserve the new set of TX rings.  We fix it as follows:
      
      1. Instead of reserving the new set of TX rings, just ask the firmware
      to check if the new set of TX rings is available.  There is a flag in
      the firmware message to do that.  If not available, abort and the
      current TX rings will not be disabled.
      
      2. Do the actual TX ring reservation in the path that opens the NIC.
      We keep the number of TX rings currently successfully reserved.  If the
      number of TX rings is different than the reserved TX rings, we call
      firmware and reserve again.
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      98fdbe73
  19. 26 7月, 2017 1 次提交
  20. 25 7月, 2017 1 次提交