linux-toradex.git/drivers/infiniband/ulp, branch v3.2.53

IPoIB: Fix send lockup due to missed TX completion

2013-04-10T02:20:02+00:00

commit 1ee9e2aa7b31427303466776f455d43e5e3c9275 upstream.

Commit f0dc117abdfa ("IPoIB: Fix TX queue lockup with mixed UD/CM
traffic") attempts to solve an issue where unprocessed UD send
completions can deadlock the netdev.

The patch doesn't fully resolve the issue because if more than half
the tx_outstanding's were UD and all of the destinations are RC
reachable, arming the CQ doesn't solve the issue.

This patch uses the IB_CQ_REPORT_MISSED_EVENTS on the
ib_req_notify_cq().  If the rc is above 0, the UD send cq completion
callback is called directly to re-arm the send completion timer.

This issue is seen in very large parallel filesystem deployments
and the patch has been shown to correct the issue.

Reviewed-by: Dean Luick 
Signed-off-by: Mike Marciniszyn 
Signed-off-by: Roland Dreier 
Signed-off-by: Ben Hutchings

IB/srp: Avoid having aborted requests hang

2012-10-17T02:49:19+00:00

commit d8536670916a685df116b5c2cb256573fd25e4e3 upstream.

We need to call scsi_done() for commands after we abort them.

Signed-off-by: Bart Van Assche 
Acked-by: David Dillow 
Signed-off-by: Roland Dreier 
Signed-off-by: Ben Hutchings

IB/srp: Fix use-after-free in srp_reset_req()

2012-10-17T02:49:18+00:00

commit 9b796d06d5d1b1e85ae2316a283ea11dd739ef96 upstream.

srp_free_req() uses the scsi_cmnd structure contents to unmap
buffers, so we must invoke srp_free_req() before we release
ownership of that structure.

Signed-off-by: Bart Van Assche 
Acked-by: David Dillow 
Signed-off-by: Roland Dreier 
Signed-off-by: Ben Hutchings

IPoIB: Fix use-after-free of multicast object

2012-10-17T02:49:17+00:00

commit bea1e22df494a729978e7f2c54f7bda328f74bc3 upstream.

Fix a crash in ipoib_mcast_join_task().  (with help from Or Gerlitz)

Commit c8c2afe360b7 ("IPoIB: Use rtnl lock/unlock when changing device
flags") added a call to rtnl_lock() in ipoib_mcast_join_task(), which
is run from the ipoib_workqueue, and hence the workqueue can't be
flushed from the context of ipoib_stop().

In the current code, ipoib_stop() (which doesn't flush the workqueue)
calls ipoib_mcast_dev_flush(), which goes and deletes all the
multicast entries.  This takes place without any synchronization with
a possible running instance of ipoib_mcast_join_task() for the same
ipoib device, leading to a crash due to NULL pointer dereference.

Fix this by making sure that the workqueue is flushed before
ipoib_mcast_dev_flush() is called.  To make that possible, we move the
RTNL-lock wrapped code to ipoib_mcast_join_finish().

Signed-off-by: Patrick McHardy 
Signed-off-by: Roland Dreier 
Signed-off-by: Ben Hutchings

IB/srp: Fix a race condition

2012-09-12T02:37:04+00:00

commit 220329916c72ee3d54ae7262b215a050f04a18fc upstream.

Avoid a crash caused by the scmnd->scsi_done(scmnd) call in
srp_process_rsp() being invoked with scsi_done == NULL.  This can
happen if a reply is received during or after a command abort.

Reported-by: Joseph Glanville 
Reference: http://marc.info/?l=linux-rdma&m=134314367801595
Acked-by: David Dillow 
Signed-off-by: Bart Van Assche 
Signed-off-by: Roland Dreier 
Signed-off-by: Ben Hutchings

IB/iser: Post initial receive buffers before sending the final login request

2012-04-02T16:52:36+00:00

commit 89e984e2c2cd14f77ccb26c47726ac7f13b70ae8 upstream.

An iser target may send iscsi NO-OP PDUs as soon as it marks the iSER
iSCSI session as fully operative.  This means that there is window
where there are no posted receive buffers on the initiator side, so
it's possible for the iSER RC connection to break because of RNR NAK /
retry errors.  To fix this, rely on the flags bits in the login
request to have FFP (0x3) in the lower nibble as a marker for the
final login request, and post an initial chunk of receive buffers
before sending that login request instead of after getting the login
response.

Signed-off-by: Or Gerlitz 
Signed-off-by: Roland Dreier 
Signed-off-by: Greg Kroah-Hartman

IPoIB: Stop lying about hard_header_len and use skb->cb to stash LL addresses

2012-03-01T00:31:03+00:00

[ Upstream commit 936d7de3d736e0737542641269436f4b5968e9ef ]

Commit a0417fa3a18a ("net: Make qdisc_skb_cb upper size bound
explicit.") made it possible for a netdev driver to use skb->cb
between its header_ops.create method and its .ndo_start_xmit
method.  Use this in ipoib_hard_header() to stash away the LL address
(GID + QPN), instead of the "ipoib_pseudoheader" hack.  This allows
IPoIB to stop lying about its hard_header_len, which will let us fix
the L2 check for GRO.

Signed-off-by: Roland Dreier 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Merge branches 'cxgb4', 'ipoib', 'misc' and 'qib' into for-next

2011-11-30T02:01:53+00:00

IB: Fix RCU lockdep splats

2011-11-29T21:37:11+00:00

Commit f2c31e32b37 ("net: fix NULL dereferences in check_peer_redir()")
forgot to take care of infiniband uses of dst neighbours.

Many thanks to Marc Aurele who provided a nice bug report and feedback.

Reported-by: Marc Aurele La France 
Signed-off-by: Eric Dumazet 
Cc: David Miller 
Cc: 
Signed-off-by: Roland Dreier

IB/ipoib: Prevent hung task or softlockup processing multicast response

2011-11-29T21:20:02+00:00

This following can occur with ipoib when processing a multicast reponse:

    BUG: soft lockup - CPU#0 stuck for 67s! [ib_mad1:982]
    Modules linked in: ...
    CPU 0:
    Modules linked in: ...
    Pid: 982, comm: ib_mad1 Not tainted 2.6.32-131.0.15.el6.x86_64 #1 ProLiant DL160 G5
    RIP: 0010:[]  [] _spin_unlock_irqrestore+0x17/0x20
    RSP: 0018:ffff8802119ed860  EFLAGS: 00000246
    0000000000000004 RBX: ffff8802119ed860 RCX: 000000000000a299
    RDX: ffff88021086c700 RSI: 0000000000000246 RDI: 0000000000000246
    RBP: ffffffff8100bc8e R08: ffff880210ac229c R09: 0000000000000000
    R10: ffff88021278aab8 R11: 0000000000000000 R12: ffff8802119ed860
    R13: ffffffff8100be6e R14: 0000000000000001 R15: 0000000000000003
    FS:  0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: 00000000006d4840 CR3: 0000000209aa5000 CR4: 00000000000406f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Call Trace:
    [] ? ipoib_mcast_send+0x157/0x480 [ib_ipoib]
    [] ? apic_timer_interrupt+0xe/0x20
    [] ? apic_timer_interrupt+0xe/0x20
    [] ? ipoib_path_lookup+0x124/0x2d0 [ib_ipoib]
    [] ? ipoib_start_xmit+0x17c/0x430 [ib_ipoib]
    [] ? dev_hard_start_xmit+0x2c8/0x3f0
    [] ? sch_direct_xmit+0x15a/0x1c0
    [] ? dev_queue_xmit+0x388/0x4d0
    [] ? ipoib_mcast_join_finish+0x2c7/0x510 [ib_ipoib]
    [] ? ipoib_mcast_sendonly_join_complete+0x1b8/0x1f0 [ib_ipoib]
    [] ? mcast_work_handler+0x1a6/0x710 [ib_sa]
    [] ? ib_send_mad+0xfe/0x3c0 [ib_mad]
    [] ? ib_get_cached_lmc+0xa3/0xb0 [ib_core]
    [] ? join_handler+0xeb/0x200 [ib_sa]
    [] ? ib_sa_mcmember_rec_callback+0x5c/0xa0 [ib_sa]
    [] ? recv_handler+0x3c/0x70 [ib_sa]
    [] ? ib_mad_completion_handler+0x844/0x9d0 [ib_mad]
    [] ? ib_mad_completion_handler+0x0/0x9d0 [ib_mad]
    [] ? worker_thread+0x170/0x2a0
    [] ? autoremove_wake_function+0x0/0x40
    [] ? worker_thread+0x0/0x2a0
    [] ? kthread+0x96/0xa0
    [] ? child_rip+0xa/0x20

Coinciding with stack trace is the following message:

    ib0: ib_address_create failed

The code below in ipoib_mcast_join_finish() will note the above
failure in the address handle but otherwise continue:

                ah = ipoib_create_ah(dev, priv->pd, &av);
                if (!ah) {
                        ipoib_warn(priv, "ib_address_create failed\n");
                } else {

The while loop at the bottom of ipoib_mcast_join_finish() will attempt
to send queued multicast packets in mcast->pkt_queue and eventually
end up in ipoib_mcast_send():

        if (!mcast->ah) {
                if (skb_queue_len(&mcast->pkt_queue) < IPOIB_MAX_MCAST_QUEUE)
                        skb_queue_tail(&mcast->pkt_queue, skb);
                else {
                        ++dev->stats.tx_dropped;
                        dev_kfree_skb_any(skb);
                }

My read is that the code will requeue the packet and return to the
ipoib_mcast_join_finish() while loop and the stage is set for the
"hung" task diagnostic as the while loop never sees a non-NULL ah, and
will do nothing to resolve.

There are GFP_ATOMIC allocates in the provider routines, so this is
possible and should be dealt with.

The test that induced the failure is associated with a host SM on the
same server during a shutdown.

This patch causes ipoib_mcast_join_finish() to exit with an error
which will flush the queued mcast packets.  Nothing is done to unwind
the QP attached state so that subsequent sends from above will retry
the join.

Reviewed-by: Ram Vepa 
Reviewed-by: Gary Leshner 
Signed-off-by: Mike Marciniszyn 
Signed-off-by: Roland Dreier