linux-stable.git/drivers/infiniband/ulp, branch v3.16.41

IB/srp: Fix infinite loop when FMR sg[0].offset != 0

2017-02-23T03:54:10+00:00

commit 681cc3608355737c1effebc8145f95c8c3344bc3 upstream.

Avoid that mapping an sg-list in which the first element has a
non-zero offset triggers an infinite loop when using FMR. This
patch makes the FMR mapping code similar to that of ib_sg_to_pages().

Note: older Mellanox HCAs do not support non-zero offsets for FMR.
See also commit 8c4037b501ac ("IB/srp: always avoid non-zero offsets
into an FMR").

Reported-by: Alex Estrin 
Signed-off-by: Bart Van Assche 
Signed-off-by: Doug Ledford 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

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

2016-11-20T01:17:31+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 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

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

2016-11-20T01:17:22+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: Ben Hutchings

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

2016-08-22T21:38:09+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: Ben Hutchings

IB/IPoIB: Fix race between ipoib_remove_one to sysfs functions

2016-08-22T21:38:09+00:00

commit 198b12f77084244d310888dd5d643083cb5c2aa1 upstream.

In ipoib_remove_one the driver holds the rtnl_lock and tries to do some
operation like dev_change_flags or unregister_netdev, while sysfs
callback like ipoib_vlan_delete holds sysfs mutex and tries to hold the
rtnl_lock via rtnl_trylock() and restart_syscall() if the lock is not
free, meanwhile ipoib_remove_one tries to get the sysfs lock in order to
free its sysfs directory, and we will get  a->b, b->a deadlock.

    Trace like the following:

        schedule+0x37/0x80
        schedule_preempt_disabled+0xe/0x10
        __mutex_lock_slowpath+0xb5/0x120
        mutex_lock+0x23/0x40
        rtnl_lock+0x15/0x20
        netdev_run_todo+0x17c/0x320
        rtnl_unlock+0xe/0x10
        ipoib_vlan_delete+0x11b/0x1b0 [ib_ipoib]
        delete_child+0x54/0x80 [ib_ipoib]
        dev_attr_store+0x18/0x30
        sysfs_kf_write+0x37/0x40
        mutex_lock+0x16/0x40
        SyS_write+0x55/0xc0
        entry_SYSCALL_64_fastpath+0x16/0x75
    And
        schedule+0x37/0x80
        __kernfs_remove+0x1a8/0x260
        ? wake_atomic_t_function+0x60/0x60
        kernfs_remove+0x25/0x40
        sysfs_remove_dir+0x50/0x80
        kobject_del+0x18/0x50
        device_del+0x19f/0x260
        netdev_unregister_kobject+0x6a/0x80
        rollback_registered_many+0x1fd/0x340
        rollback_registered+0x3c/0x70
        unregister_netdevice_queue+0x55/0xc0
        unregister_netdev+0x20/0x30
        ipoib_remove_one+0x114/0x1b0 [ib_ipoib]
        ib_unregister_client+0x4a/0x170 [ib_core]
        ? find_module_all+0x71/0xa0
        ipoib_cleanup_module+0x10/0x94 [ib_ipoib]
        SyS_delete_module+0x1b5/0x210
        entry_SYSCALL_64_fastpath+0x16/0x75

The fix is by checking the flag IPOIB_FLAG_INTF_ON_DESTROY in order to
get out from the sysfs function.

Fixes: 862096a8bbf8 ("IB/ipoib: Add more rtnl_link_ops callbacks")
Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support")
Signed-off-by: Erez Shitrit 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

IB/srpt: Simplify srpt_handle_tsk_mgmt()

2016-04-30T22:05:52+00:00

commit 51093254bf879bc9ce96590400a87897c7498463 upstream.

Let the target core check task existence instead of the SRP target
driver. Additionally, let the target core check the validity of the
task management request instead of the ib_srpt driver.

This patch fixes the following kernel crash:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
IP: [] srpt_handle_new_iu+0x6d7/0x790 [ib_srpt]
Oops: 0002 [#1] SMP
Call Trace:
 [] srpt_process_completion+0xde/0x570 [ib_srpt]
 [] srpt_compl_thread+0x13f/0x160 [ib_srpt]
 [] kthread+0xcf/0xe0
 [] ret_from_fork+0x7c/0xb0

Signed-off-by: Bart Van Assche 
Fixes: 3e4f574857ee ("ib_srpt: Convert TMR path to target_submit_tmr")
Tested-by: Alex Estrin 
Reviewed-by: Christoph Hellwig 
Cc: Nicholas Bellinger 
Cc: Sagi Grimberg 
Signed-off-by: Doug Ledford 
[bwh: Backported to 3.16: deleted code is slightly different]
Signed-off-by: Ben Hutchings

IB/srp: Fix possible send queue overflow

2016-01-11T10:50:19+00:00

commit 09c0c0bea500a9ad362589990ee316c9b2482f44 upstream.

When using work request based memory registration (fast_reg)
we must reserve SQ entries for registration and invalidation
in addition to send operations. Each IO consumes 3 SQ entries
(registration, send, invalidation) so we need to allocate 3x
larger send-queue instead of 2x.

Signed-off-by: Sagi Grimberg 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Doug Ledford 
[ luis: backported to 3.16:
  - change function srp_create_target_ib() instead of srp_create_ch_ib()
  - adjusted context ]
Signed-off-by: Luis Henriques

iser-target: remove command with state ISTATE_REMOVE

2015-10-09T13:41:06+00:00

commit a4c15cd957cbd728f685645de7a150df5912591a upstream.

As documented in iscsit_sequence_cmd:
/*
 * Existing callers for iscsit_sequence_cmd() will silently
 * ignore commands with CMDSN_LOWER_THAN_EXP, so force this
 * return for CMDSN_MAXCMDSN_OVERRUN as well..
 */

We need to silently finish a command when it's in ISTATE_REMOVE.
This fixes an teardown hang we were seeing where a mis-behaved
initiator (triggered by allocation error injections) sent us a
cmdsn which was lower than expected.

Signed-off-by: Jenny Derzhavetz 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Luis Henriques

iser-target: release stale iser connections

2015-06-30T16:15:26+00:00

commit 2f1b6b7d9a815f341b18dfd26a363f37d4d3c96a upstream.

When receiving a new iser connect request we serialize
the pending requests by adding the newly created iser connection
to the np accept list and let the login thread process the connect
request one by one (np_accept_wait).

In case we received a disconnect request before the iser_conn
has begun processing (still linked in np_accept_list) we should
detach it from the list and clean it up and not have the login
thread process a stale connection. We do it only when the connection
state is not already terminating (initiator driven disconnect) as
this might lead us to access np_accept_mutex after the np was released
in live shutdown scenarios.

Signed-off-by: Sagi Grimberg 
Signed-off-by: Jenny Falkovich 
Signed-off-by: Nicholas Bellinger 
[ luis: backported to 3.16:
  - use 'conn_accept_node' instead of 'accept_node' (field renamed by
    dac6ab305d73 "iser-target: Remove conn_ prefix from struct isert_conn members")
  - adjusted context ]
Signed-off-by: Luis Henriques

iser-target: Fix variable-length response error completion

2015-06-30T16:15:25+00:00

commit 9253e667ab50fd4611a60e1cdd6a6e05a1d91cf1 upstream.

Since commit "2426bd456a6 target: Report correct response ..."
we might get a command with data_size that does not fit to
the number of allocated data sg elements. Given that we rely on
cmd t_data_nents which might be different than the data_size,
we sometimes receive local length error completion. The correct
approach would be to take the command data_size into account when
constructing the ib sg_list.

Signed-off-by: Sagi Grimberg 
Signed-off-by: Jenny Falkovich 
Signed-off-by: Nicholas Bellinger 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques