--- /dev/null
+From a4c15cd957cbd728f685645de7a150df5912591a Mon Sep 17 00:00:00 2001
+From: Jenny Derzhavetz <jennyf@mellanox.com>
+Date: Sun, 6 Sep 2015 14:52:20 +0300
+Subject: iser-target: remove command with state ISTATE_REMOVE
+
+From: Jenny Derzhavetz <jennyf@mellanox.com>
+
+commit a4c15cd957cbd728f685645de7a150df5912591a upstream.
+
+As documented in iscsit_sequence_cmd:
+/*
+ * Existing callers for iscsit_sequence_cmd() will silently
+ * ignore commands with CMDSN_LOWER_THAN_EXP, so force this
+ * return for CMDSN_MAXCMDSN_OVERRUN as well..
+ */
+
+We need to silently finish a command when it's in ISTATE_REMOVE.
+This fixes an teardown hang we were seeing where a mis-behaved
+initiator (triggered by allocation error injections) sent us a
+cmdsn which was lower than expected.
+
+Signed-off-by: Jenny Derzhavetz <jennyf@mellanox.com>
+Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
+Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/ulp/isert/ib_isert.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/drivers/infiniband/ulp/isert/ib_isert.c
++++ b/drivers/infiniband/ulp/isert/ib_isert.c
+@@ -2634,9 +2634,16 @@ isert_get_dataout(struct iscsi_conn *con
+ static int
+ isert_immediate_queue(struct iscsi_conn *conn, struct iscsi_cmd *cmd, int state)
+ {
+- int ret;
++ struct isert_cmd *isert_cmd = iscsit_priv_cmd(cmd);
++ int ret = 0;
+
+ switch (state) {
++ case ISTATE_REMOVE:
++ spin_lock_bh(&conn->cmd_lock);
++ list_del_init(&cmd->i_conn_node);
++ spin_unlock_bh(&conn->cmd_lock);
++ isert_put_cmd(isert_cmd, true);
++ break;
+ case ISTATE_SEND_NOPIN_WANT_RESPONSE:
+ ret = isert_put_nopin(cmd, conn, false);
+ break;
--- /dev/null
+From 537b604c8b3aa8b96fe35f87dd085816552e294c Mon Sep 17 00:00:00 2001
+From: Michal Hocko <mhocko@suse.com>
+Date: Thu, 27 Aug 2015 20:16:37 +0200
+Subject: scsi: fix scsi_error_handler vs. scsi_host_dev_release race
+
+From: Michal Hocko <mhocko@suse.com>
+
+commit 537b604c8b3aa8b96fe35f87dd085816552e294c upstream.
+
+b9d5c6b7ef57 ("[SCSI] cleanup setting task state in
+scsi_error_handler()") has introduced a race between scsi_error_handler
+and scsi_host_dev_release resulting in the hang when the device goes
+away because scsi_error_handler might miss a wake up:
+
+CPU0 CPU1
+scsi_error_handler scsi_host_dev_release
+ kthread_stop()
+ kthread_should_stop()
+ test_bit(KTHREAD_SHOULD_STOP)
+ set_bit(KTHREAD_SHOULD_STOP)
+ wake_up_process()
+ wait_for_completion()
+
+ set_current_state(TASK_INTERRUPTIBLE)
+ schedule()
+
+The most straightforward solution seems to be to invert the ordering of
+the set_current_state and kthread_should_stop.
+
+The issue has been noticed during reboot test on a 3.0 based kernel but
+the current code seems to be affected in the same way.
+
+[jejb: additional comment added]
+Reported-and-debugged-by: Mike Mayer <Mike.Meyer@teradata.com>
+Signed-off-by: Michal Hocko <mhocko@suse.com>
+Reviewed-by: Dan Williams <dan.j.williams@intel.com>
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Signed-off-by: James Bottomley <JBottomley@Odin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/scsi_error.c | 11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+--- a/drivers/scsi/scsi_error.c
++++ b/drivers/scsi/scsi_error.c
+@@ -2149,8 +2149,17 @@ int scsi_error_handler(void *data)
+ * We never actually get interrupted because kthread_run
+ * disables signal delivery for the created thread.
+ */
+- while (!kthread_should_stop()) {
++ while (true) {
++ /*
++ * The sequence in kthread_stop() sets the stop flag first
++ * then wakes the process. To avoid missed wakeups, the task
++ * should always be in a non running state before the stop
++ * flag is checked
++ */
+ set_current_state(TASK_INTERRUPTIBLE);
++ if (kthread_should_stop())
++ break;
++
+ if ((shost->host_failed == 0 && shost->host_eh_scheduled == 0) ||
+ shost->host_failed != shost->host_busy) {
+ SCSI_LOG_ERROR_RECOVERY(1,