Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 05 6月, 2017 1 次提交
  3. 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
  5. 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
  7. 23 2月, 2017 1 次提交
  9. 31 1月, 2017 2 次提交
  11. 23 1月, 2017 1 次提交
  13. 17 1月, 2017 1 次提交
  15. 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
  17. 15 12月, 2016 1 次提交
  19. 30 10月, 2016 1 次提交
  21. 24 9月, 2016 1 次提交
  23. 05 7月, 2016 1 次提交
  25. 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
  27. 17 2月, 2016 1 次提交
  29. 16 12月, 2015 1 次提交
  31. 07 12月, 2015 1 次提交
  33. 16 11月, 2015 1 次提交
  35. 22 10月, 2015 1 次提交
  37. 09 10月, 2015 1 次提交
  39. 16 6月, 2015 3 次提交
  41. 31 5月, 2015 1 次提交
  43. 25 5月, 2015 2 次提交
  45. 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
  47. 06 5月, 2015 1 次提交
  49. 03 4月, 2015 2 次提交
  51. 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
  53. 19 3月, 2015 1 次提交
  55. 09 3月, 2015 1 次提交
  57. 03 3月, 2015 1 次提交
  59. 05 2月, 2015 2 次提交
    • M
      net/mlx4_core: Fix mpt_entry initialization in mlx4_mr_rereg_mem_write() · b332068c
      由 Maor Gottlieb 提交于 
      a) Previously, mlx4_mr_rereg_write filled the MPT's start
   and length with the old MPT's values.
   Fixing the initialization to take the new start and length.

b) In addition access flags in mpt_status were initialized instead of
   status due to bad boolean operation. Fixing the operation.

c) Initialization of pd_slave caused a protection error.
   Fix - removing this initialization.

d) In resource_tracker.c: Fixing vf encoding to be one-based.

Fixes: e630664c ('mlx4_core: Add helper functions to support MR re-registration')
Signed-off-by: NMaor Gottlieb <maorg@mellanox.com>
Signed-off-by: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b332068c
    • M
      net/mlx4_core: Port aggregation upper layer interface · 53f33ae2
      由 Moni Shoua 提交于 
      Supply interface functions to bond and unbond ports of a mlx4 internal
interfaces. Example for such an interface is the one registered by the
mlx4 IB driver under RoCE.

There are

1. Functions to go in/out to/from bonded mode
2. Function to remap virtual ports to physical ports

The bond_mutex prevents simultaneous access to data that keep status of
the device in bonded mode.

The upper mlx4 interface marks to the mlx4 core module that they
want to be subject for such bonding by setting the MLX4_INTFF_BONDING
flag. Interface which goes to/from bonded mode is re-created.

The mlx4 Ethernet driver does not set this flag when registering the
interface, the IB driver does.
Signed-off-by: NMoni Shoua <monis@mellanox.com>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      53f33ae2
  61. 28 1月, 2015 1 次提交
  63. 26 1月, 2015 1 次提交
  65. 12 12月, 2014 1 次提交
    • E
      net/mlx4: Change QP allocation scheme · ddae0349
      由 Eugenia Emantayev 提交于 
      When using BF (Blue-Flame), the QPN overrides the VLAN, CV, and SV fields
in the WQE. Thus, BF may only be used for QPNs with bits 6,7 unset.

The current Ethernet driver code reserves a Tx QP range with 256b alignment.

This is wrong because if there are more than 64 Tx QPs in use,
QPNs >= base + 65 will have bits 6/7 set.

This problem is not specific for the Ethernet driver, any entity that
tries to reserve more than 64 BF-enabled QPs should fail. Also, using
ranges is not necessary here and is wasteful.

The new mechanism introduced here will support reservation for
"Eth QPs eligible for BF" for all drivers: bare-metal, multi-PF, and VFs
(when hypervisors support WC in VMs). The flow we use is:

1. In mlx4_en, allocate Tx QPs one by one instead of a range allocation,
   and request "BF enabled QPs" if BF is supported for the function

2. In the ALLOC_RES FW command, change param1 to:
a. param1[23:0]  - number of QPs
b. param1[31-24] - flags controlling QPs reservation

Bit 31 refers to Eth blueflame supported QPs. Those QPs must have
bits 6 and 7 unset in order to be used in Ethernet.

Bits 24-30 of the flags are currently reserved.

When a function tries to allocate a QP, it states the required attributes
for this QP. Those attributes are considered "best-effort". If an attribute,
such as Ethernet BF enabled QP, is a must-have attribute, the function has
to check that attribute is supported before trying to do the allocation.

In a lower layer of the code, mlx4_qp_reserve_range masks out the bits
which are unsupported. If SRIOV is used, the PF validates those attributes
and masks out unsupported attributes as well. In order to notify VFs which
attributes are supported, the VF uses QUERY_FUNC_CAP command. This command's
mailbox is filled by the PF, which notifies which QP allocation attributes
it supports.
Signed-off-by: NEugenia Emantayev <eugenia@mellanox.co.il>
Signed-off-by: NMatan Barak <matanb@mellanox.com>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ddae0349