On 05/06/2020 10:27, John Garry wrote:
On 05/06/2020 09:33, Ming Lei wrote:
LLDD does not use request->tag - it generates its own.
and suggest you to double check
hisi_sas's queue mapping which has to be exactly same with blk-mq's
mapping.
scheduler=none is ok, so I am skeptical of a problem there.
Please try the following patch, and we may not drain in-flight
requests correctly:
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index 97bb650f0ed6..ae110e2754bf 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -265,6 +265,7 @@ struct bt_tags_iter_data {
#define BT_TAG_ITER_RESERVED (1 << 0)
#define BT_TAG_ITER_STARTED (1 << 1)
+#define BT_TAG_ITER_STATIC_RQS (1 << 2)
static bool bt_tags_iter(struct sbitmap *bitmap, unsigned int bitnr,
void *data)
{
@@ -280,7 +281,10 @@ static bool bt_tags_iter(struct sbitmap *bitmap,
unsigned int bitnr, void *data)
* We can hit rq == NULL here, because the tagging functions
* test and set the bit before assining ->rqs[].
assigning
*/
- rq = tags->rqs[bitnr];
+ if (iter_data->flags & BT_TAG_ITER_STATIC_RQS)
+ rq = tags->static_rqs[bitnr];
+ else
+ rq = tags->rqs[bitnr];
if (!rq)
return true;
if ((iter_data->flags & BT_TAG_ITER_STARTED) &&
@@ -335,11 +339,13 @@ static void __blk_mq_all_tag_iter(struct
blk_mq_tags *tags,
* indicates whether or not @rq is a reserved request. Return
* true to continue iterating tags, false to stop.
* @priv: Will be passed as second argument to @fn.
+ *
+ * Caller has to pass the tag map from which requests are allocated.
*/
void blk_mq_all_tag_iter(struct blk_mq_tags *tags, busy_tag_iter_fn
*fn,
void *priv)
{
- return __blk_mq_all_tag_iter(tags, fn, priv, 0);
+ return __blk_mq_all_tag_iter(tags, fn, priv,
BT_TAG_ITER_STATIC_RQS);
}
/**
ok, so early test shows that this is ok. I didn't try scheduler=none
though.
So that looks ok for scheduler=none also.
So can we please get both patches sent formally? (I was using
Christoph's patch, which introduces__blk_mq_get_driver_tag()).
Cheers,
John
Ps. if sending a series, can you also fix up the spelling mistake? I
don't think it's worth sending a single patch for that, which may conflict.
