linux-stable.git/drivers/scsi/libfc, branch linux-3.19.y

scsi: drop reason argument from ->change_queue_depth

2014-11-24T13:45:27+00:00

Drop the now unused reason argument from the ->change_queue_depth method.
Also add a return value to scsi_adjust_queue_depth, and rename it to
scsi_change_queue_depth now that it can be used as the default
->change_queue_depth implementation.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Mike Christie 
Reviewed-by: Hannes Reinecke

scsi: avoid ->change_queue_depth indirection for queue full tracking

2014-11-24T13:45:12+00:00

All drivers use the implementation for ramping the queue up and down, so
instead of overloading the change_queue_depth method call the
implementation diretly if the driver opts into it by setting the
track_queue_depth flag in the host template.

Note that a few drivers validated the new queue depth in their
change_queue_depth method, but as we never go over the queue depth
set during slave_configure or the sysfs file this isn't nessecary
and can safely be removed.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Mike Christie 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Venkatesh Srinivas

scsi: don't set tagging state from scsi_adjust_queue_depth

2014-11-12T10:19:43+00:00

Remove the tagged argument from scsi_adjust_queue_depth, and just let it
handle the queue depth.  For most drivers those two are fairly separate,
given that most modern drivers don't care about the SCSI "tagged" status
of a command at all, and many old drivers allow queuing of multiple
untagged commands in the driver.

Instead we start out with the ->simple_tags flag set before calling
->slave_configure, which is how all drivers actually looking at
->simple_tags except for one worke anyway.  The one other case looks
broken, but I've kept the behavior as-is for now.

Except for that we only change ->simple_tags from the ->change_queue_type,
and when rejecting a tag message in a single driver, so keeping this
churn out of scsi_adjust_queue_depth is a clear win.

Now that the usage of scsi_adjust_queue_depth is more obvious we can
also remove all the trivial instances in ->slave_alloc or ->slave_configure
that just set it to the cmd_per_lun default.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Mike Christie 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Martin K. Petersen

scsi: always assign block layer tags if enabled

2014-11-12T10:19:43+00:00

Allow a driver to ask for block layer tags by setting .use_blk_tags in the
host template, in which case it will always see a valid value in
request->tag, similar to the behavior when using blk-mq.  This means even
SCSI "untagged" commands will now have a tag, which is especially useful
when using a host-wide tag map.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Mike Christie 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Hannes Reinecke

scsi: provide a generic change_queue_type method

2014-11-12T10:19:39+00:00

Most drivers use exactly the same implementation, so provide it as a
library function.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Bart Van Assche 
Reviewed-by: Mike Christie 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Hannes Reinecke

libfc: Replace rcu_assign_pointer() with RCU_INIT_POINTER()

2014-09-30T07:28:36+00:00

The uses of "rcu_assign_pointer()" are NULLing out the pointers.
According to RCU_INIT_POINTER()'s block comment:
"1.   This use of RCU_INIT_POINTER() is NULLing out the pointer"
it is better to use it instead of rcu_assign_pointer() because it has a
smaller overhead.

The following Coccinelle semantic patch was used:
@@
@@

- rcu_assign_pointer
+ RCU_INIT_POINTER
  (..., NULL)

Signed-off-by: Andreea-Cristina Bernat 
Acked-by: Vasu Dev 
Signed-off-by: Christoph Hellwig

fcp: Do not interpret check condition as underrun

2013-09-04T20:52:35+00:00

This patch avoids that the FCoE initiator sends a REC message after
having received a SCSI response with non-zero status and non-zero
DATA IN buffer length.

Signed-off-by: Bart Van Assche 
Cc: Neil Horman 
Signed-off-by: Robert Love

libfc: Do not invoke the response handler after fc_exch_done()

2013-09-04T20:45:22+00:00

While the FCoE initiator driver invokes fc_exch_done() from inside
the libfc response handler, FCoE target drivers typically invoke
fc_exch_done() from outside the libfc response handler. The object
fc_exch.arg points at may disappear as soon as fc_exch_done() has
finished. So it's important not to invoke the response handler
function after fc_exch_done() has finished. Modify libfc such that
this guarantee is provided if fc_exch_done() is invoked from
outside a response handler. This patch fixes a sporadic crash in
FCoE target implementations after a command has been aborted.

Signed-off-by: Bart Van Assche 
Cc: Neil Horman 
Signed-off-by: Robert Love

libfc: Reduce exchange lock contention in fc_exch_recv_abts()

2013-09-04T20:37:53+00:00

Reduce the time during which the exchange lock is held by allocating
a frame before obtaining the exchange lock.

Signed-off-by: Bart Van Assche 
Cc: Neil Horman 
Signed-off-by: Robert Love

libfc: Avoid that sending after an abort triggers a kernel warning

2013-09-04T20:30:43+00:00

Calling fc_seq_send() after an ABTS message has been received triggers
a kernel warning (WARN_ON(!(ep->esb_stat & ESB_ST_SEQ_INIT))). Avoid
this by returning -ENXIO to the caller if fc_seq_send() is invoked after
an ABTS message has been received.

Signed-off-by: Bart Van Assche 
Cc: Neil Horman 
Signed-off-by: Robert Love