From: Bart Van Assche <Bart.VanAssche@wdc.com>
To: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
Damien Le Moal <Damien.LeMoal@wdc.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>
Cc: "hch@lst.de" <hch@lst.de>
Subject: Re: [PATCH] sd_zbc: Write unlock zone from sd_uninit_cmnd()
Date: Wed, 9 Aug 2017 15:24:43 +0000 [thread overview]
Message-ID: <1502292282.2356.3.camel@wdc.com> (raw)
In-Reply-To: <0e79dcda-29d8-58e3-ed20-b7b6e8db4b10@wdc.com>
On Wed, 2017-08-09 at 14:15 +0900, Damien Le Moal wrote:
> Overall, yes, that is possible. However, considering only write commands
> to a single zone, since at any time only one command is dequeued (the
> one holding the zone lock), having the "lock+dequeue" and
> "unlock+requeue" both atomic prevent any reordering of write commands
> directed to that zone. The first command in the queue for the zone will
> either (1) get the zone lock and be dequeued OR (2) stay in the queue.
> In case (1), the next write for the zone will hit case (2) until the
> dispatch command completes. If the dispatch command is requeued (at the
> dispatch queue head), we hit back again the (1) or (2) cases, without
> any change in the order. Isnt't it ?
Hello Damien,
Commands that get requeued are not reinserted at their original position
in the request queue but usually at a different position. This is what makes
requeueing cause request reordering. Anyway, can you check whether replacing
patch "sd_zbc: Write unlock zone from sd_uninit_cmnd()" with the (untested)
patch below does not trigger any lockups and prevents request reordering?
Since that patch keeps the zone lock across requeuing attempts it should
prevent request reordering.
Thanks,
Bart.
---
drivers/scsi/sd_zbc.c | 8 ++++++++
include/scsi/scsi_cmnd.h | 3 +++
2 files changed, 11 insertions(+)
diff --git a/drivers/scsi/sd_zbc.c b/drivers/scsi/sd_zbc.c
index 96855df9f49d..6d18b1bd3b26 100644
--- a/drivers/scsi/sd_zbc.c
+++ b/drivers/scsi/sd_zbc.c
@@ -290,10 +290,15 @@ int sd_zbc_write_lock_zone(struct scsi_cmnd *cmd)
* threads running on different CPUs write to the same
* zone (with a synchronized sequential pattern).
*/
+ if (cmd->flags & SCMD_IN_PROGRESS)
+ return BLKPREP_OK;
+
if (sdkp->zones_wlock &&
test_and_set_bit(zno, sdkp->zones_wlock))
return BLKPREP_DEFER;
+ cmd->flags |= SCMD_IN_PROGRESS;
+
return BLKPREP_OK;
}
@@ -302,6 +307,9 @@ void sd_zbc_write_unlock_zone(struct scsi_cmnd *cmd)
struct request *rq = cmd->request;
struct scsi_disk *sdkp = scsi_disk(rq->rq_disk);
+ WARN_ON_ONCE(!(cmd->flags & SCMD_IN_PROGRESS));
+ cmd->flags &= ~SCMD_IN_PROGRESS;
+
if (sdkp->zones_wlock) {
unsigned int zno = sd_zbc_zone_no(sdkp, blk_rq_pos(rq));
WARN_ON_ONCE(!test_bit(zno, sdkp->zones_wlock));
diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index a1266d318c85..f18c812094b5 100644
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
@@ -57,6 +57,9 @@ struct scsi_pointer {
/* for scmd->flags */
#define SCMD_TAGGED (1 << 0)
#define SCMD_UNCHECKED_ISA_DMA (1 << 1)
+#ifdef CONFIG_BLK_DEV_ZONED
+#define SCMD_IN_PROGRESS (1 << 2)
+#endif
struct scsi_cmnd {
struct scsi_request req;
next prev parent reply other threads:[~2017-08-09 15:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-08 4:17 [PATCH] sd_zbc: Write unlock zone from sd_uninit_cmnd() Damien Le Moal
2017-08-08 15:07 ` Bart Van Assche
2017-08-09 2:19 ` Damien Le Moal
2017-08-09 2:47 ` Damien Le Moal
2017-08-09 3:57 ` Bart Van Assche
2017-08-09 4:07 ` Damien Le Moal
2017-08-09 4:15 ` Bart Van Assche
2017-08-09 5:15 ` Damien Le Moal
2017-08-09 15:24 ` Bart Van Assche [this message]
2017-08-10 2:14 ` Damien Le Moal
2017-08-10 3:09 ` Damien Le Moal
2017-08-10 15:35 ` Bart Van Assche
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=1502292282.2356.3.camel@wdc.com \
--to=bart.vanassche@wdc.com \
--cc=Damien.LeMoal@wdc.com \
--cc=hch@lst.de \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox