linux-stable.git/drivers/target, branch v4.11.2

iscsi-target: Set session_fall_back_to_erl0 when forcing reinstatement

2017-05-20T12:49:40+00:00

commit 197b806ae5db60c6f609d74da04ddb62ea5e1b00 upstream.

While testing modification of per se_node_acl queue_depth forcing
session reinstatement via lio_target_nacl_cmdsn_depth_store() ->
core_tpg_set_initiator_node_queue_depth(), a hung task bug triggered
when changing cmdsn_depth invoked session reinstatement while an iscsi
login was already waiting for session reinstatement to complete.

This can happen when an outstanding se_cmd descriptor is taking a
long time to complete, and session reinstatement from iscsi login
or cmdsn_depth change occurs concurrently.

To address this bug, explicitly set session_fall_back_to_erl0 = 1
when forcing session reinstatement, so session reinstatement is
not attempted if an active session is already being shutdown.

This patch has been tested with two scenarios.  The first when
iscsi login is blocked waiting for iscsi session reinstatement
to complete followed by queue_depth change via configfs, and
second when queue_depth change via configfs us blocked followed
by a iscsi login driven session reinstatement.

Note this patch depends on commit d36ad77f702 to handle multiple
sessions per se_node_acl when changing cmdsn_depth, and for
pre v4.5 kernels will need to be included for stable as well.

Reported-by: Gary Guo 
Tested-by: Gary Guo 
Cc: Gary Guo 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

target/fileio: Fix zero-length READ and WRITE handling

2017-05-20T12:49:39+00:00

commit 59ac9c078141b8fd0186c0b18660a1b2c24e724e upstream.

This patch fixes zero-length READ and WRITE handling in target/FILEIO,
which was broken a long time back by:

Since:

  commit d81cb44726f050d7cf1be4afd9cb45d153b52066
  Author: Paolo Bonzini 
  Date:   Mon Sep 17 16:36:11 2012 -0700

      target: go through normal processing for all zero-length commands

which moved zero-length READ and WRITE completion out of target-core,
to doing submission into backend driver code.

To address this, go ahead and invoke target_complete_cmd() for any
non negative return value in fd_do_rw().

Signed-off-by: Bart Van Assche 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Christoph Hellwig 
Cc: Andy Grover 
Cc: David Disseldorp 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

target: Fix compare_and_write_callback handling for non GOOD status

2017-05-20T12:49:39+00:00

commit a71a5dc7f833943998e97ca8fa6a4c708a0ed1a9 upstream.

Following the bugfix for handling non SAM_STAT_GOOD COMPARE_AND_WRITE
status during COMMIT phase in commit 9b2792c3da1, the same bug exists
for the READ phase as well.

This would manifest first as a lost SCSI response, and eventual
hung task during fabric driver logout or re-login, as existing
shutdown logic waited for the COMPARE_AND_WRITE se_cmd->cmd_kref
to reach zero.

To address this bug, compare_and_write_callback() has been changed
to set post_ret = 1 and return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE
as necessary to signal failure status.

Reported-by: Bill Borsari 
Cc: Bill Borsari 
Tested-by: Gary Guo 
Cc: Gary Guo 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

tcmu: Skip Data-Out blocks before gathering Data-In buffer for BIDI case

2017-04-02T23:18:51+00:00

For the bidirectional case, the Data-Out buffer blocks will always at
the head of the tcmu_cmd's bitmap, and before gathering the Data-In
buffer, first of all it should skip the Data-Out ones, or the device
supporting BIDI commands won't work.

Fixed: 26418649eead ("target/user: Introduce data_bitmap, replace
		data_length/data_head/data_tail")
Reported-by: Ilias Tsitsimpis 
Tested-by: Ilias Tsitsimpis 
Signed-off-by: Xiubo Li 
Cc: stable@vger.kernel.org # 4.6+
Signed-off-by: Nicholas Bellinger

iscsi-target: Drop work-around for legacy GlobalSAN initiator

2017-04-02T21:10:16+00:00

Once upon a time back in 2009, a work-around was added to support
the GlobalSAN iSCSI initiator v3.3 for MacOSX, which during login
did not propose nor respond to MaxBurstLength, FirstBurstLength,
DefaultTime2Wait and DefaultTime2Retain keys.

The work-around in iscsi_check_proposer_for_optional_reply()
allowed the missing keys to be proposed, but did not require
waiting for a response before moving to full feature phase
operation.  This allowed GlobalSAN v3.3 to work out-of-the
box, and for many years we didn't run into login interopt
issues with any other initiators..

Until recently, when Martin tried a QLogic 57840S iSCSI Offload
HBA on Windows 2016 which completed login, but subsequently
failed with:

    Got unknown iSCSI OpCode: 0x43

The issue was QLogic MSFT side did not propose DefaultTime2Wait +
DefaultTime2Retain, so LIO proposes them itself, and immediately
transitions to full feature phase because of the GlobalSAN hack.
However, the QLogic MSFT side still attempts to respond to
DefaultTime2Retain + DefaultTime2Wait, even though LIO has set
ISCSI_FLAG_LOGIN_NEXT_STAGE3 + ISCSI_FLAG_LOGIN_TRANSIT
in last login response.

So while the QLogic MSFT side should have been proposing these
two keys to start, it was doing the correct thing per RFC-3720
attempting to respond to proposed keys before transitioning to
full feature phase.

All that said, recent versions of GlobalSAN iSCSI (v5.3.0.541)
does correctly propose the four keys during login, making the
original work-around moot.

So in order to allow QLogic MSFT to run unmodified as-is, go
ahead and drop this long standing work-around.

Reported-by: Martin Svec 
Cc: Martin Svec 
Cc: Himanshu Madhani 
Cc: Arun Easi 
Cc: stable@vger.kernel.org # 3.1+
Signed-off-by: Nicholas Bellinger

target: Fix ALUA transition state race between multiple initiators

2017-03-31T06:12:40+00:00

Multiple threads could be writing to alua_access_state at
the same time, or there could be multiple STPGs in flight
(different initiators sending them or one initiator sending
them to different ports), or a combo of both and the
core_alua_do_transition_tg_pt calls will race with each other.

Because from the last patches we no longer delay running
core_alua_do_transition_tg_pt_work, there does not seem to be
any point in running that in a workqueue. And, we always
wait for it to complete one way or another, so we can sleep
in this code path. So, this patch made over target-pending just adds a
mutex and does the work core_alua_do_transition_tg_pt_work was doing in
core_alua_do_transition_tg_pt.

There is also no need to use an atomic for the
tg_pt_gp_alua_access_state. In core_alua_do_transition_tg_pt we will
test and set it under the transition mutex. And, it is a int/32 bits
so in the other places where it is read, we will never see it partially
updated.

Signed-off-by: Mike Christie 
Signed-off-by: Nicholas Bellinger

iscsi-target: Propigate queue_data_in + queue_status errors

2017-03-31T03:34:58+00:00

This patch changes iscsi-target to propagate iscsit_transport
->iscsit_queue_data_in() and ->iscsit_queue_status() callback
errors, back up into target-core.

This allows target-core to retry failed iscsit_transport
callbacks using internal queue-full logic.

Reported-by: Potnuri Bharat Teja 
Reviewed-by: Potnuri Bharat Teja 
Tested-by: Potnuri Bharat Teja 
Cc: Potnuri Bharat Teja 
Reported-by: Steve Wise 
Cc: Steve Wise 
Cc: Sagi Grimberg 
Signed-off-by: Nicholas Bellinger

target: Fix unknown fabric callback queue-full errors

2017-03-31T03:34:31+00:00

This patch fixes a set of queue-full response handling
bugs, where outgoing responses are leaked when a fabric
driver is propagating non -EAGAIN or -ENOMEM errors
to target-core.

It introduces TRANSPORT_COMPLETE_QF_ERR state used to
signal when CHECK_CONDITION status should be generated,
when fabric driver ->write_pending(), ->queue_data_in(),
or ->queue_status() callbacks fail with non -EAGAIN or
-ENOMEM errors, and data-transfer should not be retried.

Note all fabric driver -EAGAIN and -ENOMEM errors are
still retried indefinately with associated data-transfer
callbacks, following existing queue-full logic.

Also fix two missing ->queue_status() queue-full cases
related to CMD_T_ABORTED w/ TAS status handling.

Reported-by: Potnuri Bharat Teja 
Reviewed-by: Potnuri Bharat Teja 
Tested-by: Potnuri Bharat Teja 
Cc: Potnuri Bharat Teja 
Reported-by: Steve Wise 
Cc: Steve Wise 
Cc: Sagi Grimberg 
Signed-off-by: Nicholas Bellinger

tcmu: Fix wrongly calculating of the base_command_size

2017-03-30T08:36:53+00:00

The t_data_nents and t_bidi_data_nents are the numbers of the
segments, but it couldn't be sure the block size equals to size
of the segment.

For the worst case, all the blocks are discontiguous and there
will need the same number of iovecs, that's to say: blocks == iovs.
So here just set the number of iovs to block count needed by tcmu
cmd.

Tested-by: Ilias Tsitsimpis 
Reviewed-by: Mike Christie 
Signed-off-by: Xiubo Li 
Cc: stable@vger.kernel.org # 3.18+
Signed-off-by: Nicholas Bellinger

tcmu: Fix possible overwrite of t_data_sg's last iov[]

2017-03-30T08:36:52+00:00

If there has BIDI data, its first iov[] will overwrite the last
iov[] for se_cmd->t_data_sg.

To fix this, we can just increase the iov pointer, but this may
introuduce a new memory leakage bug: If the se_cmd->data_length
and se_cmd->t_bidi_data_sg->length are all not aligned up to the
DATA_BLOCK_SIZE, the actual length needed maybe larger than just
sum of them.

So, this could be avoided by rounding all the data lengthes up
to DATA_BLOCK_SIZE.

Reviewed-by: Mike Christie 
Tested-by: Ilias Tsitsimpis 
Reviewed-by: Bryant G. Ly 
Signed-off-by: Xiubo Li 
Cc: stable@vger.kernel.org # 3.18+
Signed-off-by: Nicholas Bellinger