<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/target, branch linux-4.11.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>iscsi-target: Reject immediate data underflow larger than SCSI transfer length</title>
<updated>2017-06-29T11:02:52+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2017-06-08T03:29:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=47a1f8d951dc1e167d7b4a63792303b51377d1c3'/>
<id>47a1f8d951dc1e167d7b4a63792303b51377d1c3</id>
<content type='text'>
commit abb85a9b512e8ca7ad04a5a8a6db9664fe644974 upstream.

When iscsi WRITE underflow occurs there are two different scenarios
that can happen.

Normally in practice, when an EDTL vs. SCSI CDB TRANSFER LENGTH
underflow is detected, the iscsi immediate data payload is the
smaller SCSI CDB TRANSFER LENGTH.

That is, when a host fabric LLD is using a fixed size EDTL for
a specific control CDB, the SCSI CDB TRANSFER LENGTH and actual
SCSI payload ends up being smaller than EDTL.  In iscsi, this
means the received iscsi immediate data payload matches the
smaller SCSI CDB TRANSFER LENGTH, because there is no more
SCSI payload to accept beyond SCSI CDB TRANSFER LENGTH.

However, it's possible for a malicous host to send a WRITE
underflow where EDTL is larger than SCSI CDB TRANSFER LENGTH,
but incoming iscsi immediate data actually matches EDTL.

In the wild, we've never had a iscsi host environment actually
try to do this.

For this special case, it's wrong to truncate part of the
control CDB payload and continue to process the command during
underflow when immediate data payload received was larger than
SCSI CDB TRANSFER LENGTH, so go ahead and reject and drop the
bogus payload as a defensive action.

Note this potential bug was originally relaxed by the following
for allowing WRITE underflow in MSFT FCP host environments:

   commit c72c5250224d475614a00c1d7e54a67f77cd3410
   Author: Roland Dreier &lt;roland@purestorage.com&gt;
   Date:   Wed Jul 22 15:08:18 2015 -0700

      target: allow underflow/overflow for PR OUT etc. commands

Cc: Roland Dreier &lt;roland@purestorage.com&gt;
Cc: Mike Christie &lt;mchristi@redhat.com&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Cc: Martin K. Petersen &lt;martin.petersen@oracle.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 abb85a9b512e8ca7ad04a5a8a6db9664fe644974 upstream.

When iscsi WRITE underflow occurs there are two different scenarios
that can happen.

Normally in practice, when an EDTL vs. SCSI CDB TRANSFER LENGTH
underflow is detected, the iscsi immediate data payload is the
smaller SCSI CDB TRANSFER LENGTH.

That is, when a host fabric LLD is using a fixed size EDTL for
a specific control CDB, the SCSI CDB TRANSFER LENGTH and actual
SCSI payload ends up being smaller than EDTL.  In iscsi, this
means the received iscsi immediate data payload matches the
smaller SCSI CDB TRANSFER LENGTH, because there is no more
SCSI payload to accept beyond SCSI CDB TRANSFER LENGTH.

However, it's possible for a malicous host to send a WRITE
underflow where EDTL is larger than SCSI CDB TRANSFER LENGTH,
but incoming iscsi immediate data actually matches EDTL.

In the wild, we've never had a iscsi host environment actually
try to do this.

For this special case, it's wrong to truncate part of the
control CDB payload and continue to process the command during
underflow when immediate data payload received was larger than
SCSI CDB TRANSFER LENGTH, so go ahead and reject and drop the
bogus payload as a defensive action.

Note this potential bug was originally relaxed by the following
for allowing WRITE underflow in MSFT FCP host environments:

   commit c72c5250224d475614a00c1d7e54a67f77cd3410
   Author: Roland Dreier &lt;roland@purestorage.com&gt;
   Date:   Wed Jul 22 15:08:18 2015 -0700

      target: allow underflow/overflow for PR OUT etc. commands

Cc: Roland Dreier &lt;roland@purestorage.com&gt;
Cc: Mike Christie &lt;mchristi@redhat.com&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Cc: Martin K. Petersen &lt;martin.petersen@oracle.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 delayed logout processing greater than SECONDS_FOR_LOGOUT_COMP</title>
<updated>2017-06-29T11:02:52+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2017-06-03T12:35:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=600966d6bc4d1602c17849e9b4eee68240054f0e'/>
<id>600966d6bc4d1602c17849e9b4eee68240054f0e</id>
<content type='text'>
commit 105fa2f44e504c830697b0c794822112d79808dc upstream.

This patch fixes a BUG() in iscsit_close_session() that could be
triggered when iscsit_logout_post_handler() execution from within
tx thread context was not run for more than SECONDS_FOR_LOGOUT_COMP
(15 seconds), and the TCP connection didn't already close before
then forcing tx thread context to automatically exit.

This would manifest itself during explicit logout as:

[33206.974254] 1 connection(s) still exist for iSCSI session to iqn.1993-08.org.debian:01:3f5523242179
[33206.980184] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 2100.772 msecs
[33209.078643] ------------[ cut here ]------------
[33209.078646] kernel BUG at drivers/target/iscsi/iscsi_target.c:4346!

Normally when explicit logout attempt fails, the tx thread context
exits and iscsit_close_connection() from rx thread context does the
extra cleanup once it detects conn-&gt;conn_logout_remove has not been
cleared by the logout type specific post handlers.

To address this special case, if the logout post handler in tx thread
context detects conn-&gt;tx_thread_active has already been cleared, simply
return and exit in order for existing iscsit_close_connection()
logic from rx thread context do failed logout cleanup.

Reported-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Tested-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Cc: Mike Christie &lt;mchristi@redhat.com&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Cc: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Tested-by: Gary Guo &lt;ghg@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 105fa2f44e504c830697b0c794822112d79808dc upstream.

This patch fixes a BUG() in iscsit_close_session() that could be
triggered when iscsit_logout_post_handler() execution from within
tx thread context was not run for more than SECONDS_FOR_LOGOUT_COMP
(15 seconds), and the TCP connection didn't already close before
then forcing tx thread context to automatically exit.

This would manifest itself during explicit logout as:

[33206.974254] 1 connection(s) still exist for iSCSI session to iqn.1993-08.org.debian:01:3f5523242179
[33206.980184] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 2100.772 msecs
[33209.078643] ------------[ cut here ]------------
[33209.078646] kernel BUG at drivers/target/iscsi/iscsi_target.c:4346!

Normally when explicit logout attempt fails, the tx thread context
exits and iscsit_close_connection() from rx thread context does the
extra cleanup once it detects conn-&gt;conn_logout_remove has not been
cleared by the logout type specific post handlers.

To address this special case, if the logout post handler in tx thread
context detects conn-&gt;tx_thread_active has already been cleared, simply
return and exit in order for existing iscsit_close_connection()
logic from rx thread context do failed logout cleanup.

Reported-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Tested-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Cc: Mike Christie &lt;mchristi@redhat.com&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Cc: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Tested-by: Gary Guo &lt;ghg@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: Fix kref-&gt;refcount underflow in transport_cmd_finish_abort</title>
<updated>2017-06-29T11:02:52+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2017-06-03T03:00:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=852a804236ee6d04ec45e639d047b7c88e5e96d8'/>
<id>852a804236ee6d04ec45e639d047b7c88e5e96d8</id>
<content type='text'>
commit 73d4e580ccc5c3e05cea002f18111f66c9c07034 upstream.

This patch fixes a se_cmd-&gt;cmd_kref underflow during CMD_T_ABORTED
when a fabric driver drops it's second reference from below the
target_core_tmr.c based callers of transport_cmd_finish_abort().

Recently with the conversion of kref to refcount_t, this bug was
manifesting itself as:

[705519.601034] refcount_t: underflow; use-after-free.
[705519.604034] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 20116.512 msecs
[705539.719111] ------------[ cut here ]------------
[705539.719117] WARNING: CPU: 3 PID: 26510 at lib/refcount.c:184 refcount_sub_and_test+0x33/0x51

Since the original kref atomic_t based kref_put() didn't check for
underflow and only invoked the final callback when zero was reached,
this bug did not manifest in practice since all se_cmd memory is
using preallocated tags.

To address this, go ahead and propigate the existing return from
transport_put_cmd() up via transport_cmd_finish_abort(), and
change transport_cmd_finish_abort() + core_tmr_handle_tas_abort()
callers to only do their local target_put_sess_cmd() if necessary.

Reported-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Tested-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Cc: Mike Christie &lt;mchristi@redhat.com&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Cc: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Tested-by: Gary Guo &lt;ghg@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 73d4e580ccc5c3e05cea002f18111f66c9c07034 upstream.

This patch fixes a se_cmd-&gt;cmd_kref underflow during CMD_T_ABORTED
when a fabric driver drops it's second reference from below the
target_core_tmr.c based callers of transport_cmd_finish_abort().

Recently with the conversion of kref to refcount_t, this bug was
manifesting itself as:

[705519.601034] refcount_t: underflow; use-after-free.
[705519.604034] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 20116.512 msecs
[705539.719111] ------------[ cut here ]------------
[705539.719117] WARNING: CPU: 3 PID: 26510 at lib/refcount.c:184 refcount_sub_and_test+0x33/0x51

Since the original kref atomic_t based kref_put() didn't check for
underflow and only invoked the final callback when zero was reached,
this bug did not manifest in practice since all se_cmd memory is
using preallocated tags.

To address this, go ahead and propigate the existing return from
transport_put_cmd() up via transport_cmd_finish_abort(), and
change transport_cmd_finish_abort() + core_tmr_handle_tas_abort()
callers to only do their local target_put_sess_cmd() if necessary.

Reported-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Tested-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Cc: Mike Christie &lt;mchristi@redhat.com&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Cc: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Tested-by: Gary Guo &lt;ghg@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: Re-add check to reject control WRITEs with overflow data</title>
<updated>2017-06-14T13:07:44+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2017-05-11T08:07:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0354d1d64ff6d2f578ad7a4cce042922fc983f07'/>
<id>0354d1d64ff6d2f578ad7a4cce042922fc983f07</id>
<content type='text'>
commit 4ff83daa0200affe1894bd33d17bac404e3d78d4 upstream.

During v4.3 when the overflow/underflow check was relaxed by
commit c72c525022:

  commit c72c5250224d475614a00c1d7e54a67f77cd3410
  Author: Roland Dreier &lt;roland@purestorage.com&gt;
  Date:   Wed Jul 22 15:08:18 2015 -0700

       target: allow underflow/overflow for PR OUT etc. commands

to allow underflow/overflow for Windows compliance + FCP, a
consequence was to allow control CDBs to process overflow
data for iscsi-target with immediate data as well.

As per Roland's original change, continue to allow underflow
cases for control CDBs to make Windows compliance + FCP happy,
but until overflow for control CDBs is supported tree-wide,
explicitly reject all control WRITEs with overflow following
pre v4.3.y logic.

Reported-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Cc: Roland Dreier &lt;roland@purestorage.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 4ff83daa0200affe1894bd33d17bac404e3d78d4 upstream.

During v4.3 when the overflow/underflow check was relaxed by
commit c72c525022:

  commit c72c5250224d475614a00c1d7e54a67f77cd3410
  Author: Roland Dreier &lt;roland@purestorage.com&gt;
  Date:   Wed Jul 22 15:08:18 2015 -0700

       target: allow underflow/overflow for PR OUT etc. commands

to allow underflow/overflow for Windows compliance + FCP, a
consequence was to allow control CDBs to process overflow
data for iscsi-target with immediate data as well.

As per Roland's original change, continue to allow underflow
cases for control CDBs to make Windows compliance + FCP happy,
but until overflow for control CDBs is supported tree-wide,
explicitly reject all control WRITEs with overflow following
pre v4.3.y logic.

Reported-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Cc: Roland Dreier &lt;roland@purestorage.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 initial login PDU asynchronous socket close OOPs</title>
<updated>2017-06-07T10:10:09+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2017-05-25T04:47:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=14ba78937e8c3fa1b3d1b75206f884ace830caec'/>
<id>14ba78937e8c3fa1b3d1b75206f884ace830caec</id>
<content type='text'>
commit 25cdda95fda78d22d44157da15aa7ea34be3c804 upstream.

This patch fixes a OOPs originally introduced by:

   commit bb048357dad6d604520c91586334c9c230366a14
   Author: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
   Date:   Thu Sep 5 14:54:04 2013 -0700

   iscsi-target: Add sk-&gt;sk_state_change to cleanup after TCP failure

which would trigger a NULL pointer dereference when a TCP connection
was closed asynchronously via iscsi_target_sk_state_change(), but only
when the initial PDU processing in iscsi_target_do_login() from iscsi_np
process context was blocked waiting for backend I/O to complete.

To address this issue, this patch makes the following changes.

First, it introduces some common helper functions used for checking
socket closing state, checking login_flags, and atomically checking
socket closing state + setting login_flags.

Second, it introduces a LOGIN_FLAGS_INITIAL_PDU bit to know when a TCP
connection has dropped via iscsi_target_sk_state_change(), but the
initial PDU processing within iscsi_target_do_login() in iscsi_np
context is still running.  For this case, it sets LOGIN_FLAGS_CLOSED,
but doesn't invoke schedule_delayed_work().

The original NULL pointer dereference case reported by MNC is now handled
by iscsi_target_do_login() doing a iscsi_target_sk_check_close() before
transitioning to FFP to determine when the socket has already closed,
or iscsi_target_start_negotiation() if the login needs to exchange
more PDUs (eg: iscsi_target_do_login returned 0) but the socket has
closed.  For both of these cases, the cleanup up of remaining connection
resources will occur in iscsi_target_start_negotiation() from iscsi_np
process context once the failure is detected.

Finally, to handle to case where iscsi_target_sk_state_change() is
called after the initial PDU procesing is complete, it now invokes
conn-&gt;login_work -&gt; iscsi_target_do_login_rx() to perform cleanup once
existing iscsi_target_sk_check_close() checks detect connection failure.
For this case, the cleanup of remaining connection resources will occur
in iscsi_target_do_login_rx() from delayed workqueue process context
once the failure is detected.

Reported-by: Mike Christie &lt;mchristi@redhat.com&gt;
Reviewed-by: Mike Christie &lt;mchristi@redhat.com&gt;
Tested-by: Mike Christie &lt;mchristi@redhat.com&gt;
Cc: Mike Christie &lt;mchristi@redhat.com&gt;
Reported-by: Hannes Reinecke &lt;hare@suse.com&gt;
Cc: Hannes Reinecke &lt;hare@suse.com&gt;
Cc: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Cc: Varun Prakash &lt;varun@chelsio.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 25cdda95fda78d22d44157da15aa7ea34be3c804 upstream.

This patch fixes a OOPs originally introduced by:

   commit bb048357dad6d604520c91586334c9c230366a14
   Author: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
   Date:   Thu Sep 5 14:54:04 2013 -0700

   iscsi-target: Add sk-&gt;sk_state_change to cleanup after TCP failure

which would trigger a NULL pointer dereference when a TCP connection
was closed asynchronously via iscsi_target_sk_state_change(), but only
when the initial PDU processing in iscsi_target_do_login() from iscsi_np
process context was blocked waiting for backend I/O to complete.

To address this issue, this patch makes the following changes.

First, it introduces some common helper functions used for checking
socket closing state, checking login_flags, and atomically checking
socket closing state + setting login_flags.

Second, it introduces a LOGIN_FLAGS_INITIAL_PDU bit to know when a TCP
connection has dropped via iscsi_target_sk_state_change(), but the
initial PDU processing within iscsi_target_do_login() in iscsi_np
context is still running.  For this case, it sets LOGIN_FLAGS_CLOSED,
but doesn't invoke schedule_delayed_work().

The original NULL pointer dereference case reported by MNC is now handled
by iscsi_target_do_login() doing a iscsi_target_sk_check_close() before
transitioning to FFP to determine when the socket has already closed,
or iscsi_target_start_negotiation() if the login needs to exchange
more PDUs (eg: iscsi_target_do_login returned 0) but the socket has
closed.  For both of these cases, the cleanup up of remaining connection
resources will occur in iscsi_target_start_negotiation() from iscsi_np
process context once the failure is detected.

Finally, to handle to case where iscsi_target_sk_state_change() is
called after the initial PDU procesing is complete, it now invokes
conn-&gt;login_work -&gt; iscsi_target_do_login_rx() to perform cleanup once
existing iscsi_target_sk_check_close() checks detect connection failure.
For this case, the cleanup of remaining connection resources will occur
in iscsi_target_do_login_rx() from delayed workqueue process context
once the failure is detected.

Reported-by: Mike Christie &lt;mchristi@redhat.com&gt;
Reviewed-by: Mike Christie &lt;mchristi@redhat.com&gt;
Tested-by: Mike Christie &lt;mchristi@redhat.com&gt;
Cc: Mike Christie &lt;mchristi@redhat.com&gt;
Reported-by: Hannes Reinecke &lt;hare@suse.com&gt;
Cc: Hannes Reinecke &lt;hare@suse.com&gt;
Cc: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Cc: Varun Prakash &lt;varun@chelsio.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: Always wait for kthread_should_stop() before kthread exit</title>
<updated>2017-06-07T10:10:08+00:00</updated>
<author>
<name>Jiang Yi</name>
<email>jiangyilism@gmail.com</email>
</author>
<published>2017-05-16T09:57:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c732f3088710cbde225370473893c5f127fd1aca'/>
<id>c732f3088710cbde225370473893c5f127fd1aca</id>
<content type='text'>
commit 5e0cf5e6c43b9e19fc0284f69e5cd2b4a47523b0 upstream.

There are three timing problems in the kthread usages of iscsi_target_mod:

 - np_thread of struct iscsi_np
 - rx_thread and tx_thread of struct iscsi_conn

In iscsit_close_connection(), it calls

 send_sig(SIGINT, conn-&gt;tx_thread, 1);
 kthread_stop(conn-&gt;tx_thread);

In conn-&gt;tx_thread, which is iscsi_target_tx_thread(), when it receive
SIGINT the kthread will exit without checking the return value of
kthread_should_stop().

So if iscsi_target_tx_thread() exit right between send_sig(SIGINT...)
and kthread_stop(...), the kthread_stop() will try to stop an already
stopped kthread.

This is invalid according to the documentation of kthread_stop().

(Fix -ECONNRESET logout handling in iscsi_target_tx_thread and
 early iscsi_target_rx_thread failure case - nab)

Signed-off-by: Jiang Yi &lt;jiangyilism@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 5e0cf5e6c43b9e19fc0284f69e5cd2b4a47523b0 upstream.

There are three timing problems in the kthread usages of iscsi_target_mod:

 - np_thread of struct iscsi_np
 - rx_thread and tx_thread of struct iscsi_conn

In iscsit_close_connection(), it calls

 send_sig(SIGINT, conn-&gt;tx_thread, 1);
 kthread_stop(conn-&gt;tx_thread);

In conn-&gt;tx_thread, which is iscsi_target_tx_thread(), when it receive
SIGINT the kthread will exit without checking the return value of
kthread_should_stop().

So if iscsi_target_tx_thread() exit right between send_sig(SIGINT...)
and kthread_stop(...), the kthread_stop() will try to stop an already
stopped kthread.

This is invalid according to the documentation of kthread_stop().

(Fix -ECONNRESET logout handling in iscsi_target_tx_thread and
 early iscsi_target_rx_thread failure case - nab)

Signed-off-by: Jiang Yi &lt;jiangyilism@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: Set session_fall_back_to_erl0 when forcing reinstatement</title>
<updated>2017-05-20T12:49:40+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2017-04-25T17:55:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f9a45058a31257edf502638498c3a98602addd76'/>
<id>f9a45058a31257edf502638498c3a98602addd76</id>
<content type='text'>
commit 197b806ae5db60c6f609d74da04ddb62ea5e1b00 upstream.

While testing modification of per se_node_acl queue_depth forcing
session reinstatement via lio_target_nacl_cmdsn_depth_store() -&gt;
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 &lt;ghg@datera.io&gt;
Tested-by: Gary Guo &lt;ghg@datera.io&gt;
Cc: Gary Guo &lt;ghg@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 197b806ae5db60c6f609d74da04ddb62ea5e1b00 upstream.

While testing modification of per se_node_acl queue_depth forcing
session reinstatement via lio_target_nacl_cmdsn_depth_store() -&gt;
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 &lt;ghg@datera.io&gt;
Tested-by: Gary Guo &lt;ghg@datera.io&gt;
Cc: Gary Guo &lt;ghg@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/fileio: Fix zero-length READ and WRITE handling</title>
<updated>2017-05-20T12:49:39+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bart.vanassche@sandisk.com</email>
</author>
<published>2017-05-04T22:50:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=14a890020f947089c7d4c0ee04833cece9de5a58'/>
<id>14a890020f947089c7d4c0ee04833cece9de5a58</id>
<content type='text'>
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 &lt;pbonzini@redhat.com&gt;
  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 &lt;bart.vanassche@sandisk.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Andy Grover &lt;agrover@redhat.com&gt;
Cc: David Disseldorp &lt;ddiss@suse.de&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 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 &lt;pbonzini@redhat.com&gt;
  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 &lt;bart.vanassche@sandisk.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Andy Grover &lt;agrover@redhat.com&gt;
Cc: David Disseldorp &lt;ddiss@suse.de&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: Fix compare_and_write_callback handling for non GOOD status</title>
<updated>2017-05-20T12:49:39+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2017-04-11T23:24:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=25ed85889dcd29c19b02d12156c34fb065ba676c'/>
<id>25ed85889dcd29c19b02d12156c34fb065ba676c</id>
<content type='text'>
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-&gt;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 &lt;wgb@datera.io&gt;
Cc: Bill Borsari &lt;wgb@datera.io&gt;
Tested-by: Gary Guo &lt;ghg@datera.io&gt;
Cc: Gary Guo &lt;ghg@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 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-&gt;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 &lt;wgb@datera.io&gt;
Cc: Bill Borsari &lt;wgb@datera.io&gt;
Tested-by: Gary Guo &lt;ghg@datera.io&gt;
Cc: Gary Guo &lt;ghg@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>tcmu: Skip Data-Out blocks before gathering Data-In buffer for BIDI case</title>
<updated>2017-04-02T23:18:51+00:00</updated>
<author>
<name>Xiubo Li</name>
<email>lixiubo@cmss.chinamobile.com</email>
</author>
<published>2017-03-31T02:35:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a5d68ba85801a78c892a0eb8efb711e293ed314b'/>
<id>a5d68ba85801a78c892a0eb8efb711e293ed314b</id>
<content type='text'>
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 &lt;iliastsi@arrikto.com&gt;
Tested-by: Ilias Tsitsimpis &lt;iliastsi@arrikto.com&gt;
Signed-off-by: Xiubo Li &lt;lixiubo@cmss.chinamobile.com&gt;
Cc: stable@vger.kernel.org # 4.6+
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;iliastsi@arrikto.com&gt;
Tested-by: Ilias Tsitsimpis &lt;iliastsi@arrikto.com&gt;
Signed-off-by: Xiubo Li &lt;lixiubo@cmss.chinamobile.com&gt;
Cc: stable@vger.kernel.org # 4.6+
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
