Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 14 12月, 2017 1 次提交
  3. 10 10月, 2017 1 次提交
  5. 17 8月, 2017 1 次提交
  7. 18 7月, 2017 1 次提交
  9. 05 6月, 2017 1 次提交
  11. 09 5月, 2017 1 次提交
    • J
      net/mlx4_core: Reduce harmless SRIOV error message to debug level · 83bd5118
      由 Jack Morgenstein 提交于 
      Under SRIOV resource management, extra counters are allocated to VFs
from a free pool. If that pool is empty, the ALLOC_RES command for
a counter resource fails -- and this generates a misleading error
message in the message log.

Under SRIOV, each VF is allocated (i.e., guaranteed) 2 counters --
one counter per port. For ETH ports, the RoCE driver requests an
additional counter (above the guaranteed counters). If that request
fails, the VF RoCE driver simply uses the default (i.e., guaranteed)
counter for that port.

Thus, failing to allocate an additional counter does not constitute
a  problem, and the error message on the PF when this occurs should
be reduced to debug level.

Finally, to identify the situation that the reason for the failure is
that no resources are available to grant to the VF, we modified the
error returned by mlx4_grant_resource to -EDQUOT (Quota exceeded),
which more accurately describes the error.

Fixes: c3abb51b ("IB/mlx4: Add RoCE/IB dedicated counters")
Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83bd5118
  13. 21 4月, 2017 1 次提交
    • G
      net/mlx4: suppress 'may be used uninitialized' warning · 8dc7d11f
      由 Greg Thelen 提交于 
      gcc 4.8.4 complains that mlx4_SW2HW_MPT_wrapper() uses an uninitialized
'mpt' variable:
  drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'mlx4_SW2HW_MPT_wrapper':
  drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:2802:12: warning: 'mpt' may be used uninitialized in this function [-Wmaybe-uninitialized]
     mpt->mtt = mtt;

I think this warning is a false complaint.  mpt is only used when
mr_res_start_move_to() return zero, and in all such cases it initializes
mpt.  But apparently gcc cannot see that.

Initialize mpt to avoid the warning.
Signed-off-by: NGreg Thelen <gthelen@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8dc7d11f
  15. 23 2月, 2017 1 次提交
  17. 31 1月, 2017 2 次提交
  19. 23 1月, 2017 1 次提交
  21. 17 1月, 2017 1 次提交
  23. 30 12月, 2016 2 次提交
    • J
      net/mlx4_core: Fix raw qp flow steering rules under SRIOV · 10b1c04e
      由 Jack Morgenstein 提交于 
      Demoting simple flow steering rule priority (for DPDK) was achieved by
wrapping FW commands MLX4_QP_FLOW_STEERING_ATTACH/DETACH for the PF
as well, and forcing the priority to MLX4_DOMAIN_NIC in the wrapper
function for the PF and all VFs.

In function mlx4_ib_create_flow(), this change caused the main rule
creation for the PF to be wrapped, while it left the associated
tunnel steering rule creation unwrapped for the PF.

This mismatch caused rule deletion failures in mlx4_ib_destroy_flow()
for the PF when the detach wrapper function did not find the associated
tunnel-steering rule (since creation of that rule for the PF did not
go through the wrapper function).

Fix this by setting MLX4_QP_FLOW_STEERING_ATTACH/DETACH to be "native"
(so that the PF invocation does not go through the wrapper), and perform
the required priority demotion for the PF in the mlx4_ib_create_flow()
code path.

Fixes: 48564135 ("net/mlx4_core: Demote simple multicast and broadcast flow steering rules")
Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10b1c04e
    • J
      net/mlx4_core: Use-after-free causes a resource leak in flow-steering detach · 3b01fe7f
      由 Jack Morgenstein 提交于 
      mlx4_QP_FLOW_STEERING_DETACH_wrapper first removes the steering
rule (which results in freeing the rule structure), and then
references a field in this struct (the qp number) when releasing the
busy-status on the rule's qp.

Since this memory was freed, it could reallocated and changed.
Therefore, the qp number in the struct may be incorrect,
so that we are releasing the incorrect qp. This leaves the rule's qp
in the busy state (and could possibly release an incorrect qp as well).

Fix this by saving the qp number in a local variable, for use after
removing the steering rule.

Fixes: 2c473ae7 ("net/mlx4_core: Disallow releasing VF QPs which have steering rules")
Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b01fe7f
  25. 15 12月, 2016 1 次提交
  27. 30 10月, 2016 1 次提交
  29. 24 9月, 2016 1 次提交
  31. 05 7月, 2016 1 次提交
  33. 15 3月, 2016 1 次提交
    • A
      mlx4: add missing braces in verify_qp_parameters · baefd701
      由 Arnd Bergmann 提交于 
      The implementation of QP paravirtualization back in linux-3.7 included
some code that looks very dubious, and gcc-6 has grown smart enough
to warn about it:

drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'verify_qp_parameters':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3154:5: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation]
     if (optpar & MLX4_QP_OPTPAR_ALT_ADDR_PATH) {
     ^~
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3144:4: note: ...this 'if' clause, but it is not
    if (slave != mlx4_master_func_num(dev))

>From looking at the context, I'm reasonably sure that the indentation
is correct but that it should have contained curly braces from the
start, as the update_gid() function in the same patch correctly does.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 54679e14 ("mlx4: Implement QP paravirtualization and maintain phys_pkey_cache for smp_snoop")
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      baefd701
  35. 17 2月, 2016 1 次提交
  37. 16 12月, 2015 1 次提交
  39. 07 12月, 2015 1 次提交
  41. 16 11月, 2015 1 次提交
  43. 22 10月, 2015 1 次提交
  45. 09 10月, 2015 1 次提交
  47. 16 6月, 2015 3 次提交
  49. 31 5月, 2015 1 次提交
  51. 25 5月, 2015 2 次提交
  53. 15 5月, 2015 1 次提交
    • B
      net/mlx4: Avoid 'may be used uninitialized' warnings · c1c52db1
      由 Bjorn Helgaas 提交于 
      With a cross-compiler based on gcc-4.9, I see warnings like the following:

  drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'mlx4_SW2HW_CQ_wrapper':
  drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3048:10: error: 'cq' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    cq->mtt = mtt;

I think the warning is spurious because we only use cq when
cq_res_start_move_to() returns zero, and it always initializes *cq in that
case.  The srq case is similar.  But maybe gcc isn't smart enough to figure
that out.

Initialize cq and srq explicitly to avoid the warnings.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c1c52db1
  55. 06 5月, 2015 1 次提交
  57. 03 4月, 2015 2 次提交
  59. 25 3月, 2015 1 次提交
    • J
      net/mlx4_core: Fix GEN_EQE accessing uninitialixed mutex · bffb023a
      由 Jack Morgenstein 提交于 
      We occasionally see in procedure mlx4_GEN_EQE that the driver tries
to grab an uninitialized mutex.

This can occur in only one of two ways:
1. We are trying to generate an async event on an uninitialized slave.
2. We are trying to generate an async event on an illegal slave number
   ( < 0 or > persist->num_vfs) or an inactive slave.

To deal with #1: move the mutex initialization from specific slave init
sequence in procedure mlx_master_do_cmd to mlx4_multi_func_init() (so that
the mutex is always initialized for all slaves).

To deal with #2: check in procedure mlx4_GEN_EQE that the slave number
provided is in the proper range and that the slave is active.
Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bffb023a
  61. 19 3月, 2015 1 次提交
  63. 09 3月, 2015 1 次提交
  65. 03 3月, 2015 1 次提交
  67. 05 2月, 2015 1 次提交