<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/target, branch v3.18.52</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 VERIFY_16 handling in sbc_parse_cdb</title>
<updated>2017-04-22T05:15:03+00:00</updated>
<author>
<name>Max Lohrmann</name>
<email>post@wickenrode.com</email>
</author>
<published>2017-03-08T06:09:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4426d53ac9f00cb0fc9eb8f6fe9e66268b190117'/>
<id>4426d53ac9f00cb0fc9eb8f6fe9e66268b190117</id>
<content type='text'>
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 &lt;post@wickenrode.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;post@wickenrode.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>target/pscsi: Fix TYPE_TAPE + TYPE_MEDIMUM_CHANGER export</title>
<updated>2017-04-22T05:15:01+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2016-11-04T06:06:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b6a45bb19a450a5cc8344952338bdd090168cf08'/>
<id>b6a45bb19a450a5cc8344952338bdd090168cf08</id>
<content type='text'>
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-&gt;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 &lt;insanemal@gmail.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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-&gt;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 &lt;insanemal@gmail.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>iscsi-target: Drop work-around for legacy GlobalSAN initiator</title>
<updated>2017-04-22T05:14:58+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2017-04-02T20:36:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e204051d186017d0a715b2872a867de2fb54832c'/>
<id>e204051d186017d0a715b2872a867de2fb54832c</id>
<content type='text'>
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 &lt;martin.svec@zoner.cz&gt;
Cc: Martin Svec &lt;martin.svec@zoner.cz&gt;
Cc: Himanshu Madhani &lt;Himanshu.Madhani@cavium.com&gt;
Cc: Arun Easi &lt;arun.easi@cavium.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;martin.svec@zoner.cz&gt;
Cc: Martin Svec &lt;martin.svec@zoner.cz&gt;
Cc: Himanshu Madhani &lt;Himanshu.Madhani@cavium.com&gt;
Cc: Arun Easi &lt;arun.easi@cavium.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>iscsi-target: Fix TMR reference leak during session shutdown</title>
<updated>2017-04-22T05:14:58+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2017-03-24T00:19:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=808430c496059b98b321b80ed45286c0bebcdc9d'/>
<id>808430c496059b98b321b80ed45286c0bebcdc9d</id>
<content type='text'>
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-&gt;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-&gt;sess_cmd_map where released,
but the associated se_tmr_req was leaked and remained part
of se_device-&gt;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-&gt;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 &lt;rlm@daterainc.com&gt;
Cc: Rob Millner &lt;rlm@daterainc.com&gt;
Reported-by: Chu Yuan Lin &lt;cyl@datera.io&gt;
Cc: Chu Yuan Lin &lt;cyl@datera.io&gt;
Tested-by: Chu Yuan Lin &lt;cyl@datera.io&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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-&gt;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-&gt;sess_cmd_map where released,
but the associated se_tmr_req was leaked and remained part
of se_device-&gt;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-&gt;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 &lt;rlm@daterainc.com&gt;
Cc: Rob Millner &lt;rlm@daterainc.com&gt;
Reported-by: Chu Yuan Lin &lt;cyl@datera.io&gt;
Cc: Chu Yuan Lin &lt;cyl@datera.io&gt;
Tested-by: Chu Yuan Lin &lt;cyl@datera.io&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>target/user: Fix use-after-free of tcmu_cmds if they are expired</title>
<updated>2017-01-15T14:49:52+00:00</updated>
<author>
<name>Andy Grover</name>
<email>agrover@redhat.com</email>
</author>
<published>2016-11-22T00:35:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fcc5da2cf67993e96c9a9b3132775af11c0104ce'/>
<id>fcc5da2cf67993e96c9a9b3132775af11c0104ce</id>
<content type='text'>
[ Upstream commit d0905ca757bc40bd1ebc261a448a521b064777d7 ]

Don't free the cmd in tcmu_check_expired_cmd, it's still referenced by
an entry in our cmd_id-&gt;cmd idr. If userspace ever resumes processing,
tcmu_handle_completions() will use the now-invalid cmd pointer.

Instead, don't free cmd. It will be freed by tcmu_handle_completion() if
userspace ever recovers, or tcmu_free_device if not.

Cc: stable@vger.kernel.org
Reported-by: Bryant G Ly &lt;bgly@us.ibm.com&gt;
Tested-by: Bryant G Ly &lt;bgly@us.ibm.com&gt;
Signed-off-by: Andy Grover &lt;agrover@redhat.com&gt;
Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit d0905ca757bc40bd1ebc261a448a521b064777d7 ]

Don't free the cmd in tcmu_check_expired_cmd, it's still referenced by
an entry in our cmd_id-&gt;cmd idr. If userspace ever resumes processing,
tcmu_handle_completions() will use the now-invalid cmd pointer.

Instead, don't free cmd. It will be freed by tcmu_handle_completion() if
userspace ever recovers, or tcmu_free_device if not.

Cc: stable@vger.kernel.org
Reported-by: Bryant G Ly &lt;bgly@us.ibm.com&gt;
Tested-by: Bryant G Ly &lt;bgly@us.ibm.com&gt;
Signed-off-by: Andy Grover &lt;agrover@redhat.com&gt;
Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>target: Don't override EXTENDED_COPY xcopy_pt_cmd SCSI status code</title>
<updated>2016-11-24T02:53: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=6848fad2cbb5a1b86f1e39088ab1358a1ea81cfa'/>
<id>6848fad2cbb5a1b86f1e39088ab1358a1ea81cfa</id>
<content type='text'>
[ Upstream commit 926317de33998c112c5510301868ea9aa34097e2 ]

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;
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 926317de33998c112c5510301868ea9aa34097e2 ]

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;
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iscsi-target: Fix panic when adding second TCP connection to iSCSI session</title>
<updated>2016-08-22T16:23:16+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=7b37bc27c5c15495e601569bbe22e90744b13467'/>
<id>7b37bc27c5c15495e601569bbe22e90744b13467</id>
<content type='text'>
[ Upstream commit 8abc718de6e9e52d8a6bfdb735060554aeae25e4 ]

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;
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 8abc718de6e9e52d8a6bfdb735060554aeae25e4 ]

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;
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>target: Fix race between iscsi-target connection shutdown + ABORT_TASK</title>
<updated>2016-08-22T16:23:14+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=cb0a0062e3128d81b1d19b10f86b51f63e635e73'/>
<id>cb0a0062e3128d81b1d19b10f86b51f63e635e73</id>
<content type='text'>
[ Upstream commit 064cdd2d91c2805d788876082f31cc63506f22c3 ]

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;
Cc: stable@vger.kernel.org # 3.14+
Tested-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 064cdd2d91c2805d788876082f31cc63506f22c3 ]

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;
Cc: stable@vger.kernel.org # 3.14+
Tested-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>target: Fix missing complete during ABORT_TASK + CMD_T_FABRIC_STOP</title>
<updated>2016-08-22T16:23:13+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=b4a8ca6b17a7994dedb0d9eb07e9bf85dacd6f7e'/>
<id>b4a8ca6b17a7994dedb0d9eb07e9bf85dacd6f7e</id>
<content type='text'>
[ Upstream commit 5e2c956b8aa24d4f33ff7afef92d409eed164746 ]

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;
Cc: stable@vger.kernel.org # 3.14+
Tested-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 5e2c956b8aa24d4f33ff7afef92d409eed164746 ]

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;
Cc: stable@vger.kernel.org # 3.14+
Tested-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>target: Fix target_release_cmd_kref shutdown comp leak</title>
<updated>2016-04-18T12:49:37+00:00</updated>
<author>
<name>Himanshu Madhani</name>
<email>himanshu.madhani@qlogic.com</email>
</author>
<published>2016-03-15T05:47:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=65d83d876f80afef16c27b62d79e160bf73df652'/>
<id>65d83d876f80afef16c27b62d79e160bf73df652</id>
<content type='text'>
[ Upstream commit 5e47f1985d7107331c3f64fb3ec83d66fd73577e ]

This patch fixes an active I/O shutdown bug for fabric
drivers using target_wait_for_sess_cmds(), where se_cmd
descriptor shutdown would result in hung tasks waiting
indefinitely for se_cmd-&gt;cmd_wait_comp to complete().

To address this bug, drop the incorrect list_del_init()
usage in target_wait_for_sess_cmds() and always complete()
during se_cmd target_release_cmd_kref() put, in order to
let caller invoke the final fabric release callback
into se_cmd-&gt;se_tfo-&gt;release_cmd() code.

Reported-by: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Tested-by: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Signed-off-by: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 5e47f1985d7107331c3f64fb3ec83d66fd73577e ]

This patch fixes an active I/O shutdown bug for fabric
drivers using target_wait_for_sess_cmds(), where se_cmd
descriptor shutdown would result in hung tasks waiting
indefinitely for se_cmd-&gt;cmd_wait_comp to complete().

To address this bug, drop the incorrect list_del_init()
usage in target_wait_for_sess_cmds() and always complete()
during se_cmd target_release_cmd_kref() put, in order to
let caller invoke the final fabric release callback
into se_cmd-&gt;se_tfo-&gt;release_cmd() code.

Reported-by: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Tested-by: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Signed-off-by: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
