IB/srp: Don't set the QP into error state in tl_err_work

It is possible that not all requests can be claimed before failing
IO in tl_err_work. In this case it is very dangerous to set the QP
into error state. The functions srp_abort() and srp_reset_device()
are the functions which run in parallel.
The main trigger for this parallel code execution is congestion.

Messages like this one were visible in the kernel log:
AMD-Vi: Event logged [IO_PAGE_FAULT device=03:00.0 ...]

Tests with setting the QP into error state without failing IO
also resulted in a kernel panic before. So never set the QP
into error state if IO is possibly still in flight!

Signed-off-by: Sebastian Riemer <sebastian.riemer@profitbricks.com>
IB/srp: Make the SCSI error handlers return faster

We have a lot of LUNs. If every LUN acquires the target lock in
srp_abort() and srp_reset_device() after all IO is already failed,
then there is too much locking and the SCSI error handlers are not
left fast enough. Printing the info that we are in these error
handlers doesn't give us any useful information in that case.
All SCSI EH have to be left before reconnecting.

So check for transport offline first before printing anything or
waiting for the tl_err_work possibly running in parallel to
complete. We warn if the reconnect_work is run in parallel to
the SCSI error handling.

Signed-off-by: Sebastian Riemer <sebastian.riemer@profitbricks.com>
IB/srp: Set sdevs to running upon successful reconnect

We've noticed an issue in production that some LUNs were offline
after successful reconnect. This can be caused if the tl_err_work
triggers in parallel to the SCSI error handling.

A message like this can be found in the kernel log:
sd 8:0:0:1: Device offlined - not ready after error recovery

The function scsi_target_unblock() doesn't set SCSI devices in
SDEV_OFFLINE back to SDEV_RUNNING. So do that explicitly upon
successful reconnect.

Signed-off-by: Sebastian Riemer <sebastian.riemer@profitbricks.com>
IB/srp: Fail SCSI commands silently

Avoid that path failover in a multipath setup causes the SCSI layer
to generate kernel messages about SCSI command failures. This patch
speeds up SRP initiator operation significantly when monitoring
kernel messages over a serial port.

Signed-off-by: Sebastian Riemer <sebastian.riemer@profitbricks.com>
IB/srp: Fix deadlock if srp_handle_qp_err() is called

In QP error case it is possible to hit the deadlock below:

BUG: spinlock recursion on CPU#2, scsi_eh_7/6081
 lock: ffff8801efb5cd10, .magic: dead4ead, .owner: scsi_eh_7/6081, .owner_cpu: 2
Pid: 6081, comm: scsi_eh_7 Not tainted 3.4.23-pserver #1
Call Trace:
 [<ffffffff813d6018>] spin_dump+0x78/0xc0
 [<ffffffff813d608b>] spin_bug+0x2b/0x40
 [<ffffffff813d6236>] do_raw_spin_lock+0xf6/0x140
 [<ffffffff816b771a>] _raw_spin_lock_irqsave+0x7a/0xa0
 [<ffffffffa0228200>] ? srp_set_target_state2+0x30/0x80 [ib_srp]
 [<ffffffffa0228200>] srp_set_target_state2+0x30/0x80 [ib_srp]
 [<ffffffffa0228270>] srp_queue_tl_err_work+0x20/0x50 [ib_srp]
 [<ffffffffa0228ae1>] srp_handle_qp_err+0x61/0x70 [ib_srp]
 [<ffffffffa0228da5>] srp_send_completion+0x65/0x70 [ib_srp]
 [<ffffffffa0228fac>] __srp_get_tx_iu+0x2c/0x80 [ib_srp]
 [<ffffffffa022ad05>] srp_queuecommand+0x55/0xb60 [ib_srp]
 [<ffffffff8108fde6>] ? __lock_acquire+0x266/0x5e0
 [<ffffffff81009c33>] ? native_sched_clock+0x13/0x80
 [<ffffffff81009289>] ? sched_clock+0x9/0x10
 [<ffffffff81070d65>] ? sched_clock_cpu+0xc5/0x110
 [<ffffffffa00097ba>] ? scsi_request_fn+0x36a/0x700 [scsi_mod]
 [<ffffffffa0002747>] scsi_dispatch_cmd+0x137/0x2f0 [scsi_mod]
 [<ffffffffa0009852>] scsi_request_fn+0x402/0x700 [scsi_mod]
[shortened to relevant part]

The function srp_handle_qp_err() is called with the target lock
already held if called from srp_queuecommand(). The other caller
is the event handler managed by the IB CM.

So we have to move the locking and the state checks to the
tl_err_work itself.
We also change all work queuing to return void as we don't use
the return value.

Signed-off-by: Sebastian Riemer <sebastian.riemer@profitbricks.com>
Reported-by: Jack Wang <jinpu.wang@profitbricks.com>
IB/srp: Block SCSI requests if transport fails

After QP timeout we block all SCSI requests on the related SCSI
host until it is successfully reconnected again. This reduces
the amount of following requests which are sent to offline/
blocked SCSI devices and further speeds up the IO failing
process.

We use the scsi_target_(un)block() function pair. The offline
SCSI devices remain unblocked to fail already queued IO.

Signed-off-by: Jack Wang <jinpu.wang@profitbricks.com>
[changed patch description]
Signed-off-by: Sebastian Riemer <sebastian.riemer@profitbricks.com>
update CHANGELOG and README for 0.6.1