1. 10 Nov, 2019 1 commit
  2. 06 Nov, 2019 1 commit
  3. 29 Oct, 2019 1 commit
  4. 13 Sep, 2019 2 commits
  5. 11 Sep, 2019 1 commit
  6. 10 Sep, 2019 1 commit
  7. 14 Aug, 2019 1 commit
  8. 09 Aug, 2019 1 commit
  9. 27 Jul, 2019 1 commit
    • Davide Caratti's avatar
      mlx4/en_netdev: allow offloading VXLAN over VLAN · 91c6bfb8
      Davide Caratti authored
      
      
      ConnectX-3 Pro can offload transmission of VLAN packets with VXLAN inside:
      enable tunnel offloads in dev->vlan_features, like it's done with other
      NIC drivers (e.g. be2net and ixgbe).
      
      It's no more necessary to change dev->hw_enc_features when VXLAN are added
      or removed, since .ndo_features_check() already checks for VXLAN packet
      where the UDP destination port matches the configured value. Just set
      dev->hw_enc_features when the NIC is initialized, so that overlying VLAN
      can correctly inherit the tunnel offload capabilities.
      
      Changes since v1:
      - avoid flipping hw_enc_features, instead of calling netdev notifiers,
        thanks to Saeed Mahameed
      - squash two patches into a single one
      
      CC: Paolo Abeni <pabeni@redhat.com>
      CC: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Reviewed-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      91c6bfb8
  10. 24 Jul, 2019 1 commit
    • Arnd Bergmann's avatar
      mlx4: avoid large stack usage in mlx4_init_hca() · 9eed21c0
      Arnd Bergmann authored
      
      
      The mlx4_dev_cap and mlx4_init_hca_param are really too large
      to be put on the kernel stack, as shown by this clang warning:
      
      drivers/net/ethernet/mellanox/mlx4/main.c:3304:12: error: stack frame size of 1088 bytes in function 'mlx4_load_one' [-Werror,-Wframe-larger-than=]
      
      With gcc, the problem is the same, but it does not warn because
      it does not inline this function, and therefore stays just below
      the warning limit, while clang is just above it.
      
      Use kzalloc for dynamic allocation instead of putting them
      on stack. This gets the combined stack frame down to 424 bytes.
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9eed21c0
  11. 23 Jul, 2019 1 commit
  12. 15 Jul, 2019 1 commit
  13. 21 May, 2019 1 commit
  14. 20 May, 2019 1 commit
  15. 14 May, 2019 1 commit
  16. 08 Apr, 2019 1 commit
    • Will Deacon's avatar
      drivers: Remove explicit invocations of mmiowb() · fb24ea52
      Will Deacon authored
      
      
      mmiowb() is now implied by spin_unlock() on architectures that require
      it, so there is no reason to call it from driver code. This patch was
      generated using coccinelle:
      
      	@mmiowb@
      	@@
      	- mmiowb();
      
      and invoked as:
      
      $ for d in drivers include/linux/qed sound; do \
      spatch --include-headers --sp-file mmiowb.cocci --dir $d --in-place; done
      
      NOTE: mmiowb() has only ever guaranteed ordering in conjunction with
      spin_unlock(). However, pairing each mmiowb() removal in this patch with
      the corresponding call to spin_unlock() is not at all trivial, so there
      is a small chance that this change may regress any drivers incorrectly
      relying on mmiowb() to order MMIO writes between CPUs using lock-free
      synchronisation. If you've ended up bisecting to this commit, you can
      reintroduce the mmiowb() calls using wmb() instead, which should restore
      the old behaviour on all architectures other than some esoteric ia64
      systems.
      
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      fb24ea52
  17. 02 Apr, 2019 1 commit
  18. 24 Mar, 2019 1 commit
  19. 20 Mar, 2019 1 commit
    • Paolo Abeni's avatar
      net: remove 'fallback' argument from dev->ndo_select_queue() · a350ecce
      Paolo Abeni authored
      
      
      After the previous patch, all the callers of ndo_select_queue()
      provide as a 'fallback' argument netdev_pick_tx.
      The only exceptions are nested calls to ndo_select_queue(),
      which pass down the 'fallback' available in the current scope
      - still netdev_pick_tx.
      
      We can drop such argument and replace fallback() invocation with
      netdev_pick_tx(). This avoids an indirect call per xmit packet
      in some scenarios (TCP syn, UDP unconnected, XDP generic, pktgen)
      with device drivers implementing such ndo. It also clean the code
      a bit.
      
      Tested with ixgbe and CONFIG_FCOE=m
      
      With pktgen using queue xmit:
      threads		vanilla 	patched
      		(kpps)		(kpps)
      1		2334		2428
      2		4166		4278
      4		7895		8100
      
       v1 -> v2:
       - rebased after helper's name change
      
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a350ecce
  20. 12 Mar, 2019 3 commits
    • Jack Morgenstein's avatar
      net/mlx4_core: Fix qp mtt size calculation · 8511a653
      Jack Morgenstein authored
      Calculation of qp mtt size (in function mlx4_RST2INIT_wrapper)
      ultimately depends on function roundup_pow_of_two.
      
      If the amount of memory required by the QP is less than one page,
      roundup_pow_of_two is called with argument zero.  In this case, the
      roundup_pow_of_two result is undefined.
      
      Calling roundup_pow_of_two with a zero argument resulted in the
      following stack trace:
      
      UBSAN: Undefined behaviour in ./include/linux/log2.h:61:13
      shift exponent 64 is too large for 64-bit type 'long unsigned int'
      CPU: 4 PID: 26939 Comm: rping Tainted: G OE 4.19.0-rc1
      Hardware name: Supermicro X9DR3-F/X9DR3-F, BIOS 3.2a 07/09/2015
      Call Trace:
      dump_stack+0x9a/0xeb
      ubsan_epilogue+0x9/0x7c
      __ubsan_handle_shift_out_of_bounds+0x254/0x29d
      ? __ubsan_handle_load_invalid_value+0x180/0x180
      ? debug_show_all_locks+0x310/0x310
      ? sched_clock+0x5/0x10
      ? sched_clock+0x5/0x10
      ? sched_clock_cpu+0x18/0x260
      ? find_held_lock+0x35/0x1e0
      ? mlx4_RST2INIT_QP_wrapper+0xfb1/0x1440 [mlx4_core]
      mlx4_RST2INIT_QP_wrapper+0xfb1/0x1440 [mlx4_core]
      
      Fix this by explicitly testing for zero, and returning one if the
      argument is zero (assuming that the next higher power of 2 in this case
      should be one).
      
      Fixes: c82e9aa0
      
       ("mlx4_core: resource tracking for HCA resources used by guests")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8511a653
    • Jack Morgenstein's avatar
      net/mlx4_core: Fix locking in SRIOV mode when switching between events and polling · c07d2792
      Jack Morgenstein authored
      In procedures mlx4_cmd_use_events() and mlx4_cmd_use_polling(), we need to
      guarantee that there are no FW commands in progress on the comm channel
      (for VFs) or wrapped FW commands (on the PF) when SRIOV is active.
      
      We do this by also taking the slave_cmd_mutex when SRIOV is active.
      
      This is especially important when switching from event to polling, since we
      free the command-context array during the switch.  If there are FW commands
      in progress (e.g., waiting for a completion event), the completion event
      handler will access freed memory.
      
      Since the decision to use comm_wait or comm_poll is taken before grabbing
      the event_sem/poll_sem in mlx4_comm_cmd_wait/poll, we must take the
      slave_cmd_mutex as well (to guarantee that the decision to use events or
      polling and the call to the appropriate cmd function are atomic).
      
      Fixes: a7e1f049
      
       ("net/mlx4_core: Fix deadlock when switching between polling and event fw commands")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c07d2792
    • Jack Morgenstein's avatar
      net/mlx4_core: Fix reset flow when in command polling mode · e15ce4b8
      Jack Morgenstein authored
      As part of unloading a device, the driver switches from
      FW command event mode to FW command polling mode.
      
      Part of switching over to polling mode is freeing the command context array
      memory (unfortunately, currently, without NULLing the command context array
      pointer).
      
      The reset flow calls "complete" to complete all outstanding fw commands
      (if we are in event mode). The check for event vs. polling mode here
      is to test if the command context array pointer is NULL.
      
      If the reset flow is activated after the switch to polling mode, it will
      attempt (incorrectly) to complete all the commands in the context array --
      because the pointer was not NULLed when the driver switched over to polling
      mode.
      
      As a result, we have a use-after-free situation, which results in a
      kernel crash.
      
      For example:
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff876c4a8e>] __wake_up_common+0x2e/0x90
      PGD 0
      Oops: 0000 [#1] SMP
      Modules linked in: netconsole nfsv3 nfs_acl nfs lockd grace ...
      CPU: 2 PID: 940 Comm: kworker/2:3 Kdump: loaded Not tainted 3.10.0-862.el7.x86_64 #1
      Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006  04/28/2016
      Workqueue: events hv_eject_device_work [pci_hyperv]
      task: ffff8d1734ca0fd0 ti: ffff8d17354bc000 task.ti: ffff8d17354bc000
      RIP: 0010:[<ffffffff876c4a8e>]  [<ffffffff876c4a8e>] __wake_up_common+0x2e/0x90
      RSP: 0018:ffff8d17354bfa38  EFLAGS: 00010082
      RAX: 0000000000000000 RBX: ffff8d17362d42c8 RCX: 0000000000000000
      RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8d17362d42c8
      RBP: ffff8d17354bfa70 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000298 R11: ffff8d173610e000 R12: ffff8d17362d42d0
      R13: 0000000000000246 R14: 0000000000000000 R15: 0000000000000003
      FS:  0000000000000000(0000) GS:ffff8d1802680000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 00000000f16d8000 CR4: 00000000001406e0
      Call Trace:
       [<ffffffff876c7adc>] complete+0x3c/0x50
       [<ffffffffc04242f0>] mlx4_cmd_wake_completions+0x70/0x90 [mlx4_core]
       [<ffffffffc041e7b1>] mlx4_enter_error_state+0xe1/0x380 [mlx4_core]
       [<ffffffffc041fa4b>] mlx4_comm_cmd+0x29b/0x360 [mlx4_core]
       [<ffffffffc041ff51>] __mlx4_cmd+0x441/0x920 [mlx4_core]
       [<ffffffff877f62b1>] ? __slab_free+0x81/0x2f0
       [<ffffffff87951384>] ? __radix_tree_lookup+0x84/0xf0
       [<ffffffffc043a8eb>] mlx4_free_mtt_range+0x5b/0xb0 [mlx4_core]
       [<ffffffffc043a957>] mlx4_mtt_cleanup+0x17/0x20 [mlx4_core]
       [<ffffffffc04272c7>] mlx4_free_eq+0xa7/0x1c0 [mlx4_core]
       [<ffffffffc042803e>] mlx4_cleanup_eq_table+0xde/0x130 [mlx4_core]
       [<ffffffffc0433e08>] mlx4_unload_one+0x118/0x300 [mlx4_core]
       [<ffffffffc0434191>] mlx4_remove_one+0x91/0x1f0 [mlx4_core]
      
      The fix is to set the command context array pointer to NULL after freeing
      the array.
      
      Fixes: f5aef5aa
      
       ("net/mlx4_core: Activate reset flow upon fatal command cases")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e15ce4b8
  21. 04 Mar, 2019 1 commit
  22. 26 Feb, 2019 1 commit
  23. 18 Feb, 2019 1 commit
  24. 12 Feb, 2019 2 commits
    • Saeed Mahameed's avatar
      net/mlx4_en: Force CHECKSUM_NONE for short ethernet frames · 74abc07d
      Saeed Mahameed authored
      When an ethernet frame is padded to meet the minimum ethernet frame
      size, the padding octets are not covered by the hardware checksum.
      Fortunately the padding octets are usually zero's, which don't affect
      checksum. However, it is not guaranteed. For example, switches might
      choose to make other use of these octets.
      This repeatedly causes kernel hardware checksum fault.
      
      Prior to the cited commit below, skb checksum was forced to be
      CHECKSUM_NONE when padding is detected. After it, we need to keep
      skb->csum updated. However, fixing up CHECKSUM_COMPLETE requires to
      verify and parse IP headers, it does not worth the effort as the packets
      are so small that CHECKSUM_COMPLETE has no significant advantage.
      
      Future work: when reporting checksum complete is not an option for
      IP non-TCP/UDP packets, we can actually fallback to report checksum
      unnecessary, by looking at cqe IPOK bit.
      
      Fixes: 88078d98
      
       ("net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends")
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      74abc07d
    • Saeed Mahameed's avatar
      net/mlx4_en: Force CHECKSUM_NONE for short ethernet frames · 29dded89
      Saeed Mahameed authored
      When an ethernet frame is padded to meet the minimum ethernet frame
      size, the padding octets are not covered by the hardware checksum.
      Fortunately the padding octets are usually zero's, which don't affect
      checksum. However, it is not guaranteed. For example, switches might
      choose to make other use of these octets.
      This repeatedly causes kernel hardware checksum fault.
      
      Prior to the cited commit below, skb checksum was forced to be
      CHECKSUM_NONE when padding is detected. After it, we need to keep
      skb->csum updated. However, fixing up CHECKSUM_COMPLETE requires to
      verify and parse IP headers, it does not worth the effort as the packets
      are so small that CHECKSUM_COMPLETE has no significant advantage.
      
      Future work: when reporting checksum complete is not an option for
      IP non-TCP/UDP packets, we can actually fallback to report checksum
      unnecessary, by looking at cqe IPOK bit.
      
      Fixes: 88078d98
      
       ("net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends")
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      29dded89
  25. 08 Feb, 2019 1 commit
    • Jiri Pirko's avatar
      devlink: publish params only after driver init is done · 7c62cfb8
      Jiri Pirko authored
      
      
      Currently, user can do dump or get of param values right after the
      devlink params are registered. However the driver may not be initialized
      which is an issue. The same problem happens during notification
      upon param registration. Allow driver to publish devlink params
      whenever it is ready to handle get() ops. Note that this cannot
      be resolved by init reordering, as the "driverinit" params have
      to be available before the driver is initialized (it needs the param
      values there).
      
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Cc: Michael Chan <michael.chan@broadcom.com>
      Cc: Tariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7c62cfb8
  26. 25 Jan, 2019 3 commits
  27. 23 Jan, 2019 1 commit
    • Gustavo A. R. Silva's avatar
      net/mlx4: Mark expected switch fall-through · 482dcf7d
      Gustavo A. R. Silva authored
      
      
      In preparation to enabling -Wimplicit-fallthrough, mark switch cases
      where we are expecting to fall through.
      
      This patch fixes the following warning:
      
      drivers/net/ethernet/mellanox/mlx4/eq.c: In function ‘mlx4_eq_int’:
      drivers/net/ethernet/mellanox/mlx4/mlx4.h:219:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
        if (mlx4_debug_level)      \
           ^
      drivers/net/ethernet/mellanox/mlx4/eq.c:558:4: note: in expansion of macro ‘mlx4_dbg’
          mlx4_dbg(dev, "%s: MLX4_EVENT_TYPE_SRQ_LIMIT. srq_no=0x%x, eq 0x%x\n",
          ^~~~~~~~
      drivers/net/ethernet/mellanox/mlx4/eq.c:561:3: note: here
         case MLX4_EVENT_TYPE_SRQ_CATAS_ERROR:
         ^~~~
      
      Warning level 3 was used: -Wimplicit-fallthrough=3
      
      This patch is part of the ongoing efforts to enabling
      -Wimplicit-fallthrough.
      
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      482dcf7d
  28. 18 Jan, 2019 1 commit
  29. 08 Jan, 2019 1 commit
  30. 07 Jan, 2019 2 commits
  31. 24 Dec, 2018 1 commit
  32. 17 Dec, 2018 1 commit
  33. 09 Dec, 2018 1 commit