linux-stable.git/drivers/target, branch v3.16.46

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

2017-07-18T17:40:29+00:00

commit 1c99de981f30b3e7868b8d20ce5479fa1c0fea46 upstream.

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 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Ben Hutchings

iscsi-target: Fix TMR reference leak during session shutdown

2017-07-18T17:40:26+00:00

commit efb2ea770bb3b0f40007530bc8b0c22f36e1c5eb upstream.

This patch fixes a iscsi-target specific TMR reference leak
during session shutdown, that could occur when a TMR was
quiesced before the hand-off back to iscsi-target code
via transport_cmd_check_stop_to_fabric().

The reference leak happens because iscsit_free_cmd() was
incorrectly skipping the final target_put_sess_cmd() for
TMRs when transport_generic_free_cmd() returned zero because
the se_cmd->cmd_kref did not reach zero, due to the missing
se_cmd assignment in original code.

The result was iscsi_cmd and it's associated se_cmd memory
would be freed once se_sess->sess_cmd_map where released,
but the associated se_tmr_req was leaked and remained part
of se_device->dev_tmr_list.

This bug would manfiest itself as kernel paging request
OOPsen in core_tmr_lun_reset(), when a left-over se_tmr_req
attempted to dereference it's se_cmd pointer that had
already been released during normal session shutdown.

To address this bug, go ahead and treat ISCSI_OP_SCSI_CMD
and ISCSI_OP_SCSI_TMFUNC the same when there is an extra
se_cmd->cmd_kref to drop in iscsit_free_cmd(), and use
op_scsi to signal __iscsit_free_cmd() when the former
needs to clear any further iscsi related I/O state.

Reported-by: Rob Millner 
Cc: Rob Millner 
Reported-by: Chu Yuan Lin 
Cc: Chu Yuan Lin 
Tested-by: Chu Yuan Lin 
Signed-off-by: Nicholas Bellinger 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

target: Fix VERIFY_16 handling in sbc_parse_cdb

2017-07-18T17:40:09+00:00

commit 13603685c1f12c67a7a2427f00b63f39a2b6f7c9 upstream.

As reported by Max, the Windows 2008 R2 chkdsk utility expects
VERIFY_16 to be supported, and does not handle the returned
CHECK_CONDITION properly, resulting in an infinite loop.

The kernel will log huge amounts of this error:

kernel: TARGET_CORE[iSCSI]: Unsupported SCSI Opcode 0x8f, sending
CHECK_CONDITION.

Signed-off-by: Max Lohrmann 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Ben Hutchings

target/pscsi: Fix TYPE_TAPE + TYPE_MEDIMUM_CHANGER export

2017-07-18T17:40:08+00:00

commit a04e54f2c35823ca32d56afcd5cea5b783e2f51a upstream.

The following fixes a divide by zero OOPs with TYPE_TAPE
due to pscsi_tape_read_blocksize() failing causing a zero
sd->sector_size being propigated up via dev_attrib.hw_block_size.

It also fixes another long-standing bug where TYPE_TAPE and
TYPE_MEDIMUM_CHANGER where using pscsi_create_type_other(),
which does not call scsi_device_get() to take the device
reference.  Instead, rename pscsi_create_type_rom() to
pscsi_create_type_nondisk() and use it for all cases.

Finally, also drop a dump_stack() in pscsi_get_blocks() for
non TYPE_DISK, which in modern target-core can get invoked
via target_sense_desc_format() during CHECK_CONDITION.

Reported-by: Malcolm Haak 
Signed-off-by: Nicholas Bellinger 
[bwh: Backported to 3.16:
 - Deleted log format is slightly different
 - Cast Scsi_Host::max_sectors from unsigned short to unsigned int, to avoid
   a warning about differing types in min_not_zero()]
Signed-off-by: Ben Hutchings

target: Fix COMPARE_AND_WRITE ref leak for non GOOD status

2017-03-16T02:27:11+00:00

commit 9b2792c3da1e80f2d460167d319302a24c9ca2b7 upstream.

This patch addresses a long standing bug where the commit phase
of COMPARE_AND_WRITE would result in a se_cmd->cmd_kref reference
leak if se_cmd->scsi_status returned non SAM_STAT_GOOD.

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_post() has been changed
to drop the incorrect !cmd->scsi_status conditional that was
preventing *post_ret = 1 for being set during non SAM_STAT_GOOD
status.

This patch has been tested with SAM_STAT_CHECK_CONDITION status
from normal target_complete_cmd() callback path, as well as the
incoming __target_execute_cmd() submission failure path when
se_cmd->execute_cmd() returns non zero status.

Reported-by: Donald White 
Cc: Donald White 
Tested-by: Gary Guo 
Cc: Gary Guo 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Ben Hutchings

target: Fix early transport_generic_handle_tmr abort scenario

2017-03-16T02:27:11+00:00

commit c54eeffbe9338fa982dc853d816fda9202a13b5a upstream.

This patch fixes a bug where incoming task management requests
can be explicitly aborted during an active LUN_RESET, but who's
struct work_struct are canceled in-flight before execution.

This occurs when core_tmr_drain_tmr_list() invokes cancel_work_sync()
for the incoming se_tmr_req->task_cmd->work, resulting in cmd->work
for target_tmr_work() never getting invoked and the aborted TMR
waiting indefinately within transport_wait_for_tasks().

To address this case, perform a CMD_T_ABORTED check early in
transport_generic_handle_tmr(), and invoke the normal path via
transport_cmd_check_stop_to_fabric() to complete any TMR kthreads
blocked waiting for CMD_T_STOP in transport_wait_for_tasks().

Also, move the TRANSPORT_ISTATE_PROCESSING assignment earlier
into transport_generic_handle_tmr() so the existing check in
core_tmr_drain_tmr_list() avoids attempting abort the incoming
se_tmr_req->task_cmd->work if it has already been queued into
se_device->tmr_wq.

Reported-by: Rob Millner 
Tested-by: Rob Millner 
Cc: Rob Millner 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Nicholas Bellinger 
[bwh: Backported to 3.16:
 - Tags are 32-bit; print them with %u
 - Command tag must be looked up with get_task_tag op]
Signed-off-by: Ben Hutchings

target: Use correct SCSI status during EXTENDED_COPY exception

2017-03-16T02:27:11+00:00

commit 0583c261e6325f392c1f7a1b9112e31298e1a4bd upstream.

This patch adds the missing target_complete_cmd() SCSI status
parameter change in target_xcopy_do_work(), that was originally
missing in commit 926317de33.

It correctly propigates up the correct SCSI status during
EXTENDED_COPY exception cases, instead of always using the
hardcoded SAM_STAT_CHECK_CONDITION from original code.

This is required for ESX host environments that expect to
hit SAM_STAT_RESERVATION_CONFLICT for certain scenarios,
and SAM_STAT_CHECK_CONDITION results in non-retriable
status for these cases.

Reported-by: Nixon Vincent 
Tested-by: Nixon Vincent 
Cc: Nixon Vincent 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Ben Hutchings

target/iscsi: Fix double free in lio_target_tiqn_addtpg()

2017-03-16T02:26:37+00:00

commit a91918cd3ea11f91c68e08e1e8ce1b560447a80e upstream.

This iscsit_tpg_add_portal_group() function is only called from
lio_target_tiqn_addtpg().  Both functions free the "tpg" pointer on
error so it's a double free bug.  The memory is allocated in the caller
so it should be freed in the caller and not here.

Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1")
Signed-off-by: Dan Carpenter 
Reviewed-by: David Disseldorp 
[ bvanassche: Added "Fix" at start of patch title ]
Signed-off-by: Bart Van Assche 
Signed-off-by: Ben Hutchings

target: Don't override EXTENDED_COPY xcopy_pt_cmd SCSI status code

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

commit 926317de33998c112c5510301868ea9aa34097e2 upstream.

This patch addresses a bug where a local EXTENDED_COPY WRITE or READ
backend I/O request would always return SAM_STAT_CHECK_CONDITION,
even if underlying xcopy_pt_cmd->se_cmd generated a different
SCSI status code.

ESX host environments expect to hit SAM_STAT_RESERVATION_CONFLICT
for certain scenarios, and SAM_STAT_CHECK_CONDITION results in
non-retriable status for these cases.

Tested on v4.1.y with ESX v5.5u2+ with local IBLOCK backend copy.

Reported-by: Nixon Vincent 
Tested-by: Nixon Vincent 
Cc: Nixon Vincent 
Tested-by: Dinesh Israni 
Signed-off-by: Dinesh Israni 
Cc: Dinesh Israni 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Ben Hutchings

target: Make EXTENDED_COPY 0xe4 failure return COPY TARGET DEVICE NOT REACHABLE

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

commit 449a137846c84829a328757cd21fd9ca65c08519 upstream.

This patch addresses a bug where EXTENDED_COPY across multiple LUNs
results in a CHECK_CONDITION when the source + destination are not
located on the same physical node.

ESX Host environments expect sense COPY_ABORTED w/ COPY TARGET DEVICE
NOT REACHABLE to be returned when this occurs, in order to signal
fallback to local copy method.

As described in section 6.3.3 of spc4r22:

  "If it is not possible to complete processing of a segment because the
   copy manager is unable to establish communications with a copy target
   device, because the copy target device does not respond to INQUIRY,
   or because the data returned in response to INQUIRY indicates
   an unsupported logical unit, then the EXTENDED COPY command shall be
   terminated with CHECK CONDITION status, with the sense key set to
   COPY ABORTED, and the additional sense code set to COPY TARGET DEVICE
   NOT REACHABLE."

Tested on v4.1.y with ESX v5.5u2+ with BlockCopy across multiple nodes.

Reported-by: Nixon Vincent 
Tested-by: Nixon Vincent 
Cc: Nixon Vincent 
Tested-by: Dinesh Israni 
Signed-off-by: Dinesh Israni 
Cc: Dinesh Israni 
Signed-off-by: Nicholas Bellinger 
[bwh: Backported to 3.16: generate the sense data in
 transport_send_check_condition_and_sense() rather than adding to
 sense_info_table]
Signed-off-by: Ben Hutchings