linux-toradex.git/drivers/infiniband, branch v4.4.119

infiniband: cxgb4: use %pR format string for printing resources

2018-02-25T10:03:48+00:00

commit 3021376d6d12dd1be8a0a13c16dae8badb7766fd upstream.

The cxgb4 prints an MMIO resource using the "0x%x" and "%p" format
strings on the length and start, respective, but that
triggers a compiler warning when using a 64-bit resource_size_t
on a 32-bit architecture:

drivers/infiniband/hw/cxgb4/device.c: In function 'c4iw_rdev_open':
drivers/infiniband/hw/cxgb4/device.c:807:7: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
       (void *)pci_resource_start(rdev->lldi.pdev, 2),

This changes the format string to use %pR instead, which pretty-prints
the resource, avoids the warning and is shorter.

Signed-off-by: Arnd Bergmann 
Acked-by: Steve Wise 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

RDMA/cma: Make sure that PSN is not over max allowed

2018-02-25T10:03:39+00:00

[ Upstream commit 23a9cd2ad90543e9da3786878d2b2729c095439d ]

This patch limits the initial value for PSN to 24 bits as
spec requires.

Signed-off-by: Moni Shoua 
Signed-off-by: Mukesh Kacker 
Signed-off-by: Daniel Jurgens 
Reviewed-by: Parav Pandit 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports

2018-02-22T14:44:58+00:00

commit 852f6927594d0d3e8632c889b2ab38cbc46476ad upstream.

Allocating steerable UD QPs depends on having at least one IB port,
while releasing those QPs does not.

As a result, when there are only ETH ports, the IB (RoCE) driver
requests releasing a qp range whose base qp is zero, with
qp count zero.

When SR-IOV is enabled, and the VF driver is running on a VM over
a hypervisor which treats such qp release calls as errors
(rather than NOPs), we see lines in the VM message log like:

 mlx4_core 0002:00:02.0: Failed to release qp range base:0 cnt:0

Fix this by adding a check for a zero count in mlx4_release_qp_range()
(which thus treats releasing 0 qps as a nop), and eliminating the
check for device managed flow steering when releasing steerable UD QPs.
(Freeing ib_uc_qpns_bitmap unconditionally is also OK, since it
remains NULL when steerable UD QPs are not allocated).

Fixes: 4196670be786 ("IB/mlx4: Don't allocate range of steerable UD QPs for Ethernet-only device")
Signed-off-by: Jack Morgenstein 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman

IB/srpt: Disable RDMA access by the initiator

2018-01-17T08:35:24+00:00

commit bec40c26041de61162f7be9d2ce548c756ce0f65 upstream.

With the SRP protocol all RDMA operations are initiated by the target.
Since no RDMA operations are initiated by the initiator, do not grant
the initiator permission to submit RDMA reads or writes to the target.

Signed-off-by: Bart Van Assche 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman

iw_cxgb4: Only validate the MSN for successful completions

2018-01-02T19:33:22+00:00

commit f55688c45442bc863f40ad678c638785b26cdce6 upstream.

If the RECV CQE is in error, ignore the MSN check.  This was causing
recvs that were flushed into the sw cq to be completed with the wrong
status (BAD_MSN instead of FLUSHED).

Signed-off-by: Steve Wise 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman

RDMA/iser: Fix possible mr leak on device removal event

2017-12-25T13:22:12+00:00

[ Upstream commit ea174c9573b0e0c8bc1a7a90fe9360ccb7aa9cbb ]

When the rdma device is removed, we must cleanup all
the rdma resources within the DEVICE_REMOVAL event
handler to let the device teardown gracefully. When
this happens with live I/O, some memory regions are
occupied. Thus, track them too and dereg all the mr's.

We are safe with mr access by iscsi_iser_cleanup_task.

Reported-by: Raju Rangoju 
Signed-off-by: Sagi Grimberg 
Reviewed-by: Max Gurtovoy 
Reviewed-by: Max Gurtovoy 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop

2017-12-20T09:05:01+00:00

[ Upstream commit b4b678b06f6eef18bff44a338c01870234db0bc9 ]

When ndo_open and ndo_stop are called RTNL lock should be held.
In this specific case ipoib_ib_dev_open calls the offloaded ndo_open
which re-sets the number of TX queue assuming RTNL lock is held.
Since RTNL lock is not held, RTNL assert will fail.

Signed-off-by: Alex Vesker 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

RDMA/cma: Avoid triggering undefined behavior

2017-12-20T09:05:01+00:00

[ Upstream commit c0b64f58e8d49570aa9ee55d880f92c20ff0166b ]

According to the C standard the behavior of computations with
integer operands is as follows:
* A computation involving unsigned operands can never overflow,
  because a result that cannot be represented by the resulting
  unsigned integer type is reduced modulo the number that is one
  greater than the largest value that can be represented by the
  resulting type.
* The behavior for signed integer underflow and overflow is
  undefined.

Hence only use unsigned integers when checking for integer
overflow.

This patch is what I came up with after having analyzed the
following smatch warnings:

drivers/infiniband/core/cma.c:3448: cma_resolve_ib_udp() warn: signed overflow undefined. 'offset + conn_param->private_data_len < conn_param->private_data_len'
drivers/infiniband/core/cma.c:3505: cma_connect_ib() warn: signed overflow undefined. 'offset + conn_param->private_data_len < conn_param->private_data_len'

Signed-off-by: Bart Van Assche 
Acked-by: Sean Hefty 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

IB/mlx5: Assign send CQ and recv CQ of UMR QP

2017-12-16T09:33:55+00:00

[ Upstream commit 31fde034a8bd964a5c7c1a5663fc87a913158db2 ]

The UMR's QP is created by calling mlx5_ib_create_qp directly, and
therefore the send CQ and the recv CQ on the ibqp weren't assigned.

Assign them right after calling the mlx5_ib_create_qp to assure
that any access to those pointers will work as expected and won't
crash the system as might happen as part of reset flow.

Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
Signed-off-by: Majd Dibbiny 
Reviewed-by: Yishai Hadas 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

IB/mlx4: Increase maximal message size under UD QP

2017-12-16T09:33:55+00:00

[ Upstream commit 5f22a1d87c5315a98981ecf93cd8de226cffe6ca ]

Maximal message should be used as a limit to the max message payload allowed,
without the headers. The ConnectX-3 check is done against this value includes
the headers. When the payload is 4K this will cause the NIC to drop packets.

Increase maximal message to 8K as workaround, this shouldn't change current
behaviour because we continue to set the MTU to 4k.

To reproduce;
set MTU to 4296 on the corresponding interface, for example:
ifconfig eth0 mtu 4296 (both server and client)

On server:
ib_send_bw -c UD -d mlx4_0 -s 4096 -n 1000000 -i1 -m 4096

On client:
ib_send_bw -d mlx4_0 -c UD  -s 4096 -n 1000000 -i 1 -m 4096

Fixes: 6e0d733d9215 ("IB/mlx4: Allow 4K messages for UD QPs")
Signed-off-by: Mark Bloch 
Reviewed-by: Majd Dibbiny 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman