From: <gregkh@linuxfoundation.org>
To: mchristi@redhat.com, alexander.levin@microsoft.com,
gregkh@linuxfoundation.org, nab@linux-iscsi.org
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "tcmu: release blocks for partially setup cmds" has been added to the 4.15-stable tree
Date: Mon, 09 Apr 2018 11:36:55 +0200 [thread overview]
Message-ID: <1523266615168100@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
tcmu: release blocks for partially setup cmds
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
tcmu-release-blocks-for-partially-setup-cmds.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 10:16:32 CEST 2018
From: Mike Christie <mchristi@redhat.com>
Date: Tue, 28 Nov 2017 12:40:33 -0600
Subject: tcmu: release blocks for partially setup cmds
From: Mike Christie <mchristi@redhat.com>
[ Upstream commit 810b8153c4243d2012a6ec002ddd3bbc9a9ae8c2 ]
If we cannot setup a cmd because we run out of ring space
or global pages release the blocks before sleeping. This
prevents a deadlock where dev0 has waiting_blocks set and
needs N blocks, but dev1 to devX have each allocated N / X blocks
and also hit the global block limit so they went to sleep.
find_free_blocks is not able to take the sleeping dev's
blocks becaause their waiting_blocks is set and even
if it was not the block returned by find_last_bit could equal
dbi_max. The latter will probably never happen because
DATA_BLOCK_BITS is so high but in the next patches
DATA_BLOCK_BITS and TCMU_GLOBAL_MAX_BLOCKS will be settable so
it might be lower and could happen.
Signed-off-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/target/target_core_user.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/target/target_core_user.c
+++ b/drivers/target/target_core_user.c
@@ -805,6 +805,13 @@ tcmu_queue_cmd_ring(struct tcmu_cmd *tcm
int ret;
DEFINE_WAIT(__wait);
+ /*
+ * Don't leave commands partially setup because the unmap
+ * thread might need the blocks to make forward progress.
+ */
+ tcmu_cmd_free_data(tcmu_cmd, tcmu_cmd->dbi_cur);
+ tcmu_cmd_reset_dbi_cur(tcmu_cmd);
+
prepare_to_wait(&udev->wait_cmdr, &__wait, TASK_INTERRUPTIBLE);
pr_debug("sleeping for ring space\n");
Patches currently in stable-queue which might be from mchristi@redhat.com are
queue-4.15/tcmu-release-blocks-for-partially-setup-cmds.patch
reply other threads:[~2018-04-09 9:40 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1523266615168100@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alexander.levin@microsoft.com \
--cc=mchristi@redhat.com \
--cc=nab@linux-iscsi.org \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.