linux-toradex.git/drivers/infiniband/ulp, branch v4.4.48

IB/ipoib: move back IB LL address into the hard header

2017-02-01T07:30:53+00:00

commit fc791b6335152c5278dc4a4991bcb2d329f806f9 upstream.

After the commit 9207f9d45b0a ("net: preserve IP control block
during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
That destroy the IPoIB address information cached there,
causing a severe performance regression, as better described here:

http://marc.info/?l=linux-kernel&m=146787279825501&w=2

This change moves the data cached by the IPoIB driver from the
skb control lock into the IPoIB hard header, as done before
the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
and use skb->cb to stash LL addresses").
In order to avoid GRO issue, on packet reception, the IPoIB driver
stash into the skb a dummy pseudo header, so that the received
packets have actually a hard header matching the declared length.
To avoid changing the connected mode maximum mtu, the allocated
head buffer size is increased by the pseudo header length.

After this commit, IPoIB performances are back to pre-regression
value.

v2 -> v3: rebased
v1 -> v2: avoid changing the max mtu, increasing the head buf size

Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
Signed-off-by: Paolo Abeni 
Signed-off-by: David S. Miller 
Cc: Vasiliy Tolstov 
Cc: Nikolay Borisov 
Cc: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IB/IPoIB: Remove can't use GFP_NOIO warning

2017-01-26T07:23:47+00:00

commit 0b59970e7d96edcb3c7f651d9d48e1a59af3c3b0 upstream.

Remove the warning print of "can't use of GFP_NOIO" to avoid prints in
each QP creation when devices aren't supporting IB_QP_CREATE_USE_GFP_NOIO.

This print become more annoying when the IPoIB interface is configured
to work in connected mode.

Fixes: 09b93088d750 ('IB: Add a QP creation flag to use GFP_NOIO allocations')
Signed-off-by: Kamal Heib 
Signed-off-by: Leon Romanovsky 
Reviewed-by: Yuval Shaia 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IPoIB: Avoid reading an uninitialized member variable

2017-01-09T07:07:51+00:00

commit 11b642b84e8c43e8597de031678d15c08dd057bc upstream.

This patch avoids that Coverity reports the following:

    Using uninitialized value port_attr.state when calling printk

Fixes: commit 94232d9ce817 ("IPoIB: Start multicast join process only on active ports")
Signed-off-by: Bart Van Assche 
Cc: Erez Shitrit 
Reviewed-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IB/ipoib: Don't allow MC joins during light MC flush

2016-10-07T13:23:46+00:00

commit 344bacca8cd811809fc33a249f2738ab757d327f upstream.

This fix solves a race between light flush and on the fly joins.
Light flush doesn't set the device to down and unset IPOIB_OPER_UP
flag, this means that if while flushing we have a MC join in progress
and the QP was attached to BC MGID we can have a mismatches when
re-attaching a QP to the BC MGID.

The light flush would set the broadcast group to NULL causing an on
the fly join to rejoin and reattach to the BC MCG as well as adding
the BC MGID to the multicast list. The flush process would later on
remove the BC MGID and detach it from the QP. On the next flush
the BC MGID is present in the multicast list but not found when trying
to detach it because of the previous double attach and single detach.

[18332.714265] ------------[ cut here ]------------
[18332.717775] WARNING: CPU: 6 PID: 3767 at drivers/infiniband/core/verbs.c:280 ib_dealloc_pd+0xff/0x120 [ib_core]
...
[18332.775198] Hardware name: Red Hat KVM, BIOS Bochs 01/01/2011
[18332.779411]  0000000000000000 ffff8800b50dfbb0 ffffffff813fed47 0000000000000000
[18332.784960]  0000000000000000 ffff8800b50dfbf0 ffffffff8109add1 0000011832f58300
[18332.790547]  ffff880226a596c0 ffff880032482000 ffff880032482830 ffff880226a59280
[18332.796199] Call Trace:
[18332.798015]  [] dump_stack+0x63/0x8c
[18332.801831]  [] __warn+0xd1/0xf0
[18332.805403]  [] warn_slowpath_null+0x1d/0x20
[18332.809706]  [] ib_dealloc_pd+0xff/0x120 [ib_core]
[18332.814384]  [] ipoib_transport_dev_cleanup+0xfc/0x1d0 [ib_ipoib]
[18332.820031]  [] ipoib_ib_dev_cleanup+0x98/0x110 [ib_ipoib]
[18332.825220]  [] ipoib_dev_cleanup+0x2d8/0x550 [ib_ipoib]
[18332.830290]  [] ipoib_uninit+0x2f/0x40 [ib_ipoib]
[18332.834911]  [] rollback_registered_many+0x1aa/0x2c0
[18332.839741]  [] rollback_registered+0x31/0x40
[18332.844091]  [] unregister_netdevice_queue+0x48/0x80
[18332.848880]  [] ipoib_vlan_delete+0x1fb/0x290 [ib_ipoib]
[18332.853848]  [] delete_child+0x7d/0xf0 [ib_ipoib]
[18332.858474]  [] dev_attr_store+0x18/0x30
[18332.862510]  [] sysfs_kf_write+0x3a/0x50
[18332.866349]  [] kernfs_fop_write+0x120/0x170
[18332.870471]  [] __vfs_write+0x28/0xe0
[18332.874152]  [] ? percpu_down_read+0x1f/0x50
[18332.878274]  [] vfs_write+0xa2/0x1a0
[18332.881896]  [] SyS_write+0x46/0xa0
[18332.885632]  [] do_syscall_64+0x57/0xb0
[18332.889709]  [] entry_SYSCALL64_slow_path+0x25/0x25
[18332.894727] ---[ end trace 09ebbe31f831ef17 ]---

Fixes: ee1e2c82c245 ("IPoIB: Refresh paths instead of flushing them on SM change events")
Signed-off-by: Alex Vesker 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IB/ipoib: Fix memory corruption in ipoib cm mode connect flow

2016-10-07T13:23:46+00:00

commit 546481c2816ea3c061ee9d5658eb48070f69212e upstream.

When a new CM connection is being requested, ipoib driver copies data
from the path pointer in the CM/tx object, the path object might be
invalid at the point and memory corruption will happened later when now
the CM driver will try using that data.

The next scenario demonstrates it:
	neigh_add_path --> ipoib_cm_create_tx -->
	queue_work (pointer to path is in the cm/tx struct)
	#while the work is still in the queue,
	#the port goes down and causes the ipoib_flush_paths:
	ipoib_flush_paths --> path_free --> kfree(path)
	#at this point the work scheduled starts.
	ipoib_cm_tx_start --> copy from the (invalid)path pointer:
	(memcpy(&pathrec, &p->path->pathrec, sizeof pathrec);)
	 -> memory corruption.

To fix that the driver now starts the CM/tx connection only if that
specific path exists in the general paths database.
This check is protected with the relevant locks, and uses the gid from
the neigh member in the CM/tx object which is valid according to the ref
count that was taken by the CM/tx.

Fixes: 839fcaba35 ('IPoIB: Connected mode experimental support')
Signed-off-by: Erez Shitrit 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IB/IPoIB: Do not set skb truesize since using one linearskb

2016-09-15T06:27:49+00:00

[ Upstream commit bb6a777369449d15a4a890306d2f925cae720e1c ]

We are seeing this warning: at net/core/skbuff.c:4174
and before commit a44878d10063 ("IB/ipoib: Use one linear skb in RX flow")
skb truesize was not being set when ipoib was using just one skb.
Removing this line avoids the warning when running tcp tests like iperf.

Fixes: a44878d10063 ("IB/ipoib: Use one linear skb in RX flow")
Signed-off-by: Carol L Soto 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

IB/IPoIB: Don't update neigh validity for unresolved entries

2016-08-20T16:09:25+00:00

commit 61c78eea9516a921799c17b4c20558e2aa780fd3 upstream.

ipoib_neigh_get unconditionally updates the "alive" variable member on
any packet send.  This prevents the neighbor garbage collection from
cleaning out a dead neighbor entry if we are still queueing packets
for it.  If the queue for this neighbor is full, then don't update the
alive timestamp.  That way the neighbor can time out even if packets
are still being queued as long as none of them are being sent.

Fixes: b63b70d87741 ("IPoIB: Use a private hash table for path lookup in xmit path")
Signed-off-by: Erez Shitrit 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IB/srp: Fix a debug kernel crash

2016-06-01T19:15:53+00:00

commit 54f5c9c52d69afa55abf2b034df8d45f588466c3 upstream.

Avoid that the following BUG() is triggered against a debug
kernel:

kernel BUG at include/linux/scatterlist.h:92!
RIP: 0010:[]  [] srp_map_idb+0x199/0x1a0 [ib_srp]
Call Trace:
 [] srp_map_data+0x84a/0x890 [ib_srp]
 [] srp_queuecommand+0x1e4/0x610 [ib_srp]
 [] scsi_dispatch_cmd+0x9e/0x180
 [] scsi_request_fn+0x477/0x610
 [] __blk_run_queue+0x2e/0x40
 [] blk_delay_work+0x20/0x30
 [] process_one_work+0x197/0x480
 [] worker_thread+0x49/0x490
 [] kthread+0xea/0x100
 [] ret_from_fork+0x22/0x40

Fixes: f7f7aab1a5c0 ("IB/srp: Convert to new registration API")
Signed-off-by: Bart Van Assche 
Cc: Sagi Grimberg 
Cc: Christoph Hellwig 
Reviewed-by: Max Gurtovoy 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

iser-target: Rework connection termination

2016-04-12T16:09:03+00:00

commit 6d1fba0c2cc7efe42fd761ecbba833ed0ea7b07e upstream.

When we receive an event that triggers connection termination,
we have a a couple of things we may want to do:
1. In case we are already terminating, bailout early
2. In case we are connected but not bound, disconnect and schedule
   a connection cleanup silently (don't reinstate)
3. In case we are connected and bound, disconnect and reinstate the connection

This rework fixes a bug that was detected against a mis-behaved
initiator which rejected our rdma_cm accept, in this stage the
isert_conn is no bound and reinstate caused a bogus dereference.

What's great about this is that we don't need the
post_recv_buf_count anymore, so get rid of it.

Signed-off-by: Jenny Derzhavetz 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

iser-target: Separate flows for np listeners and connections cma events

2016-04-12T16:09:03+00:00

commit f81bf458208ef6d12b2fc08091204e3859dcdba4 upstream.

No need to restrict this check to specific events.

Signed-off-by: Jenny Derzhavetz 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman