]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
3.14-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 13 Oct 2015 19:02:58 +0000 (12:02 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 13 Oct 2015 19:02:58 +0000 (12:02 -0700)
added patches:
iser-target-remove-command-with-state-istate_remove.patch
scsi-fix-scsi_error_handler-vs.-scsi_host_dev_release-race.patch

queue-3.14/iser-target-remove-command-with-state-istate_remove.patch [new file with mode: 0644]
queue-3.14/scsi-fix-scsi_error_handler-vs.-scsi_host_dev_release-race.patch [new file with mode: 0644]
queue-3.14/series

diff --git a/queue-3.14/iser-target-remove-command-with-state-istate_remove.patch b/queue-3.14/iser-target-remove-command-with-state-istate_remove.patch
new file mode 100644 (file)
index 0000000..392b70d
--- /dev/null
@@ -0,0 +1,50 @@
+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;
diff --git a/queue-3.14/scsi-fix-scsi_error_handler-vs.-scsi_host_dev_release-race.patch b/queue-3.14/scsi-fix-scsi_error_handler-vs.-scsi_host_dev_release-race.patch
new file mode 100644 (file)
index 0000000..81673e8
--- /dev/null
@@ -0,0 +1,65 @@
+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,
index 4aaa79bd438122782e236290d87e35855d26dc2b..d59e23c97d057468a89f154ab455e53d679213b0 100644 (file)
@@ -1 +1,3 @@
 kvm-fix-zero-length-mmio-searching.patch
+scsi-fix-scsi_error_handler-vs.-scsi_host_dev_release-race.patch
+iser-target-remove-command-with-state-istate_remove.patch