<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/target, branch v3.16.45</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>target: Fix COMPARE_AND_WRITE ref leak for non GOOD status</title>
<updated>2017-03-16T02:27:11+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2017-02-06T22:28:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=690309746fc0d4727552aec9c982397199b40f34'/>
<id>690309746fc0d4727552aec9c982397199b40f34</id>
<content type='text'>
commit 9b2792c3da1e80f2d460167d319302a24c9ca2b7 upstream.

This patch addresses a long standing bug where the commit phase
of COMPARE_AND_WRITE would result in a se_cmd-&gt;cmd_kref reference
leak if se_cmd-&gt;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-&gt;cmd_kref
to reach zero.

To address this bug, compare_and_write_post() has been changed
to drop the incorrect !cmd-&gt;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-&gt;execute_cmd() returns non zero status.

Reported-by: Donald White &lt;dew@datera.io&gt;
Cc: Donald White &lt;dew@datera.io&gt;
Tested-by: Gary Guo &lt;ghg@datera.io&gt;
Cc: Gary Guo &lt;ghg@datera.io&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9b2792c3da1e80f2d460167d319302a24c9ca2b7 upstream.

This patch addresses a long standing bug where the commit phase
of COMPARE_AND_WRITE would result in a se_cmd-&gt;cmd_kref reference
leak if se_cmd-&gt;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-&gt;cmd_kref
to reach zero.

To address this bug, compare_and_write_post() has been changed
to drop the incorrect !cmd-&gt;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-&gt;execute_cmd() returns non zero status.

Reported-by: Donald White &lt;dew@datera.io&gt;
Cc: Donald White &lt;dew@datera.io&gt;
Tested-by: Gary Guo &lt;ghg@datera.io&gt;
Cc: Gary Guo &lt;ghg@datera.io&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>target: Fix early transport_generic_handle_tmr abort scenario</title>
<updated>2017-03-16T02:27:11+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2016-12-07T06:45:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=37e1b6b5c6d6dcb18a75558a5cb9ab8252c5f0c5'/>
<id>37e1b6b5c6d6dcb18a75558a5cb9ab8252c5f0c5</id>
<content type='text'>
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-&gt;task_cmd-&gt;work, resulting in cmd-&gt;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-&gt;task_cmd-&gt;work if it has already been queued into
se_device-&gt;tmr_wq.

Reported-by: Rob Millner &lt;rlm@daterainc.com&gt;
Tested-by: Rob Millner &lt;rlm@daterainc.com&gt;
Cc: Rob Millner &lt;rlm@daterainc.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
[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 &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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-&gt;task_cmd-&gt;work, resulting in cmd-&gt;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-&gt;task_cmd-&gt;work if it has already been queued into
se_device-&gt;tmr_wq.

Reported-by: Rob Millner &lt;rlm@daterainc.com&gt;
Tested-by: Rob Millner &lt;rlm@daterainc.com&gt;
Cc: Rob Millner &lt;rlm@daterainc.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
[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 &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>target: Use correct SCSI status during EXTENDED_COPY exception</title>
<updated>2017-03-16T02:27:11+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2016-10-31T07:54:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b5d330a1179d7674cdcc7fe2aa45d04d167571a1'/>
<id>b5d330a1179d7674cdcc7fe2aa45d04d167571a1</id>
<content type='text'>
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 &lt;nixon.vincent@calsoftinc.com&gt;
Tested-by: Nixon Vincent &lt;nixon.vincent@calsoftinc.com&gt;
Cc: Nixon Vincent &lt;nixon.vincent@calsoftinc.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;nixon.vincent@calsoftinc.com&gt;
Tested-by: Nixon Vincent &lt;nixon.vincent@calsoftinc.com&gt;
Cc: Nixon Vincent &lt;nixon.vincent@calsoftinc.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>target/iscsi: Fix double free in lio_target_tiqn_addtpg()</title>
<updated>2017-03-16T02:26:37+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2016-12-13T12:27:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f99aa824608ed6bb4707513f3dadd432eed818c8'/>
<id>f99aa824608ed6bb4707513f3dadd432eed818c8</id>
<content type='text'>
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 &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: David Disseldorp &lt;ddiss@suse.de&gt;
[ bvanassche: Added "Fix" at start of patch title ]
Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: David Disseldorp &lt;ddiss@suse.de&gt;
[ bvanassche: Added "Fix" at start of patch title ]
Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>target: Don't override EXTENDED_COPY xcopy_pt_cmd SCSI status code</title>
<updated>2017-02-23T03:54:18+00:00</updated>
<author>
<name>Dinesh Israni</name>
<email>ddi@datera.io</email>
</author>
<published>2016-10-11T03:22:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c0186ef8523f8d19afcec0d5be1754c71e3ca5fd'/>
<id>c0186ef8523f8d19afcec0d5be1754c71e3ca5fd</id>
<content type='text'>
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-&gt;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 &lt;nixon.vincent@calsoftinc.com&gt;
Tested-by: Nixon Vincent &lt;nixon.vincent@calsoftinc.com&gt;
Cc: Nixon Vincent &lt;nixon.vincent@calsoftinc.com&gt;
Tested-by: Dinesh Israni &lt;ddi@datera.io&gt;
Signed-off-by: Dinesh Israni &lt;ddi@datera.io&gt;
Cc: Dinesh Israni &lt;ddi@datera.io&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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-&gt;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 &lt;nixon.vincent@calsoftinc.com&gt;
Tested-by: Nixon Vincent &lt;nixon.vincent@calsoftinc.com&gt;
Cc: Nixon Vincent &lt;nixon.vincent@calsoftinc.com&gt;
Tested-by: Dinesh Israni &lt;ddi@datera.io&gt;
Signed-off-by: Dinesh Israni &lt;ddi@datera.io&gt;
Cc: Dinesh Israni &lt;ddi@datera.io&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>target: Make EXTENDED_COPY 0xe4 failure return COPY TARGET DEVICE NOT REACHABLE</title>
<updated>2017-02-23T03:54:18+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2016-10-09T00:26:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=279a47ee31bc58e0f7965eb884e70feaafee7078'/>
<id>279a47ee31bc58e0f7965eb884e70feaafee7078</id>
<content type='text'>
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 &lt;nixon.vincent@calsoftinc.com&gt;
Tested-by: Nixon Vincent &lt;nixon.vincent@calsoftinc.com&gt;
Cc: Nixon Vincent &lt;nixon.vincent@calsoftinc.com&gt;
Tested-by: Dinesh Israni &lt;ddi@datera.io&gt;
Signed-off-by: Dinesh Israni &lt;ddi@datera.io&gt;
Cc: Dinesh Israni &lt;ddi@datera.io&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
[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 &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;nixon.vincent@calsoftinc.com&gt;
Tested-by: Nixon Vincent &lt;nixon.vincent@calsoftinc.com&gt;
Cc: Nixon Vincent &lt;nixon.vincent@calsoftinc.com&gt;
Tested-by: Dinesh Israni &lt;ddi@datera.io&gt;
Signed-off-by: Dinesh Israni &lt;ddi@datera.io&gt;
Cc: Dinesh Israni &lt;ddi@datera.io&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
[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 &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iscsi-target: Fix panic when adding second TCP connection to iSCSI session</title>
<updated>2016-11-20T01:16:56+00:00</updated>
<author>
<name>Feng Li</name>
<email>lifeng1519@gmail.com</email>
</author>
<published>2016-07-11T22:15:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a916170dc57d4835691c92c06258fdbaaaf6fae5'/>
<id>a916170dc57d4835691c92c06258fdbaaaf6fae5</id>
<content type='text'>
commit 8abc718de6e9e52d8a6bfdb735060554aeae25e4 upstream.

In MC/S scenario, the conn-&gt;sess has been set NULL in
iscsi_login_non_zero_tsih_s1 when the second connection comes here,
then kernel panic.

The conn-&gt;sess will be assigned in iscsi_login_non_zero_tsih_s2. So
we should check whether it's NULL before calling.

Signed-off-by: Feng Li &lt;lifeng1519@gmail.com&gt;
Tested-by: Sumit Rai &lt;sumit.rai@calsoftinc.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8abc718de6e9e52d8a6bfdb735060554aeae25e4 upstream.

In MC/S scenario, the conn-&gt;sess has been set NULL in
iscsi_login_non_zero_tsih_s1 when the second connection comes here,
then kernel panic.

The conn-&gt;sess will be assigned in iscsi_login_non_zero_tsih_s2. So
we should check whether it's NULL before calling.

Signed-off-by: Feng Li &lt;lifeng1519@gmail.com&gt;
Tested-by: Sumit Rai &lt;sumit.rai@calsoftinc.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>target: Fix max_unmap_lba_count calc overflow</title>
<updated>2016-11-20T01:16:55+00:00</updated>
<author>
<name>Mike Christie</name>
<email>mchristi@redhat.com</email>
</author>
<published>2016-06-03T01:12:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e48994e504adbe6c4c3ff5da4f791ee0c7bc46e8'/>
<id>e48994e504adbe6c4c3ff5da4f791ee0c7bc46e8</id>
<content type='text'>
commit ea263c7fada4af8ec7fe5fcfd6e7d7705a89351b upstream.

max_discard_sectors only 32bits, and some non scsi backend
devices will set this to the max 0xffffffff, so we can end up
overflowing during the max_unmap_lba_count calculation.

This fixes a regression caused by my patch:

commit 8a9ebe717a133ba7bc90b06047f43cc6b8bcb8b3
Author: Mike Christie &lt;mchristi@redhat.com&gt;
Date:   Mon Jan 18 14:09:27 2016 -0600

    target: Fix WRITE_SAME/DISCARD conversion to linux 512b sectors

which can result in extra discards being sent to due the overflow
causing max_unmap_lba_count to be smaller than what the backing
device can actually support.

Signed-off-by: Mike Christie &lt;mchristi@redhat.com&gt;
Reviewed-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ea263c7fada4af8ec7fe5fcfd6e7d7705a89351b upstream.

max_discard_sectors only 32bits, and some non scsi backend
devices will set this to the max 0xffffffff, so we can end up
overflowing during the max_unmap_lba_count calculation.

This fixes a regression caused by my patch:

commit 8a9ebe717a133ba7bc90b06047f43cc6b8bcb8b3
Author: Mike Christie &lt;mchristi@redhat.com&gt;
Date:   Mon Jan 18 14:09:27 2016 -0600

    target: Fix WRITE_SAME/DISCARD conversion to linux 512b sectors

which can result in extra discards being sent to due the overflow
causing max_unmap_lba_count to be smaller than what the backing
device can actually support.

Signed-off-by: Mike Christie &lt;mchristi@redhat.com&gt;
Reviewed-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>target: Fix race between iscsi-target connection shutdown + ABORT_TASK</title>
<updated>2016-11-20T01:16:55+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2016-06-02T21:56:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=109e91db05361dcaef6b1715fa6e1c17c809f371'/>
<id>109e91db05361dcaef6b1715fa6e1c17c809f371</id>
<content type='text'>
commit 064cdd2d91c2805d788876082f31cc63506f22c3 upstream.

This patch fixes a race in iscsit_release_commands_from_conn() -&gt;
iscsit_free_cmd() -&gt; transport_generic_free_cmd() + wait_for_tasks=1,
where CMD_T_FABRIC_STOP could end up being set after the final
kref_put() is called from core_tmr_abort_task() context.

This results in transport_generic_free_cmd() blocking indefinately
on se_cmd-&gt;cmd_wait_comp, because the target_release_cmd_kref()
check for CMD_T_FABRIC_STOP returns false.

To address this bug, make iscsit_release_commands_from_conn()
do list_splice and set CMD_T_FABRIC_STOP early while holding
iscsi_conn-&gt;cmd_lock.  Also make iscsit_aborted_task() only
remove iscsi_cmd_t if CMD_T_FABRIC_STOP has not already been
set.

Finally in target_release_cmd_kref(), only honor fabric_stop
if CMD_T_ABORTED has been set.

Cc: Mike Christie &lt;mchristi@redhat.com&gt;
Cc: Quinn Tran &lt;quinn.tran@qlogic.com&gt;
Cc: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Tested-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 064cdd2d91c2805d788876082f31cc63506f22c3 upstream.

This patch fixes a race in iscsit_release_commands_from_conn() -&gt;
iscsit_free_cmd() -&gt; transport_generic_free_cmd() + wait_for_tasks=1,
where CMD_T_FABRIC_STOP could end up being set after the final
kref_put() is called from core_tmr_abort_task() context.

This results in transport_generic_free_cmd() blocking indefinately
on se_cmd-&gt;cmd_wait_comp, because the target_release_cmd_kref()
check for CMD_T_FABRIC_STOP returns false.

To address this bug, make iscsit_release_commands_from_conn()
do list_splice and set CMD_T_FABRIC_STOP early while holding
iscsi_conn-&gt;cmd_lock.  Also make iscsit_aborted_task() only
remove iscsi_cmd_t if CMD_T_FABRIC_STOP has not already been
set.

Finally in target_release_cmd_kref(), only honor fabric_stop
if CMD_T_ABORTED has been set.

Cc: Mike Christie &lt;mchristi@redhat.com&gt;
Cc: Quinn Tran &lt;quinn.tran@qlogic.com&gt;
Cc: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Tested-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>target: Fix missing complete during ABORT_TASK + CMD_T_FABRIC_STOP</title>
<updated>2016-11-20T01:16:55+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2016-05-25T19:25:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=003e36b65d0d371f14ebac962eaff194806fe030'/>
<id>003e36b65d0d371f14ebac962eaff194806fe030</id>
<content type='text'>
commit 5e2c956b8aa24d4f33ff7afef92d409eed164746 upstream.

During transport_generic_free_cmd() with a concurrent TMR
ABORT_TASK and shutdown CMD_T_FABRIC_STOP bit set, the
caller will be blocked on se_cmd-&gt;cmd_wait_stop completion
until the final kref_put() -&gt; target_release_cmd_kref()
has been invoked to call complete().

However, when ABORT_TASK is completed with FUNCTION_COMPLETE
in core_tmr_abort_task(), the aborted se_cmd will have already
been removed from se_sess-&gt;sess_cmd_list via list_del_init().

This results in target_release_cmd_kref() hitting the
legacy list_empty() == true check, invoking -&gt;release_cmd()
but skipping complete() to wakeup se_cmd-&gt;cmd_wait_stop
blocked earlier in transport_generic_free_cmd() code.

To address this bug, it's safe to go ahead and drop the
original list_empty() check so that fabric_stop invokes
the complete() as expected, since list_del_init() can
safely be used on a empty list.

Cc: Mike Christie &lt;mchristi@redhat.com&gt;
Cc: Quinn Tran &lt;quinn.tran@qlogic.com&gt;
Cc: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Tested-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5e2c956b8aa24d4f33ff7afef92d409eed164746 upstream.

During transport_generic_free_cmd() with a concurrent TMR
ABORT_TASK and shutdown CMD_T_FABRIC_STOP bit set, the
caller will be blocked on se_cmd-&gt;cmd_wait_stop completion
until the final kref_put() -&gt; target_release_cmd_kref()
has been invoked to call complete().

However, when ABORT_TASK is completed with FUNCTION_COMPLETE
in core_tmr_abort_task(), the aborted se_cmd will have already
been removed from se_sess-&gt;sess_cmd_list via list_del_init().

This results in target_release_cmd_kref() hitting the
legacy list_empty() == true check, invoking -&gt;release_cmd()
but skipping complete() to wakeup se_cmd-&gt;cmd_wait_stop
blocked earlier in transport_generic_free_cmd() code.

To address this bug, it's safe to go ahead and drop the
original list_empty() check so that fabric_stop invokes
the complete() as expected, since list_del_init() can
safely be used on a empty list.

Cc: Mike Christie &lt;mchristi@redhat.com&gt;
Cc: Quinn Tran &lt;quinn.tran@qlogic.com&gt;
Cc: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Tested-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
