[dm-devel] blk-mq request allocation stalls

[Keith Busch]

On Tue, 13 Jan 2015, Keith Busch wrote:
> On Tue, 13 Jan 2015, Jens Axboe wrote:
>> Making the two cases different is a bit... nonsensical. We should do this 
>> for both cases, if safe, or move the MQ_INFLIGHT flag and expand the 
>> CLONE_MASK.
>
> Expanding the clone mask won't do any good since the src doesn't come
> from blk-mq and wouldn't ever have MQ_INFLIGHT set. Blk-mq initializes
> the cmd_flags when you get one so I assumed OR'ing was safe. For the
> non-blk-mq case, we have no guarantees how the req was initialized and
> could have nonsense cmd_flags.

I take back the last part. We required blk_rq_init be called on the
request prior to calling blk_rq_prep_clone, making it safe to OR in all
the time.

diff --git a/block/blk-core.c b/block/blk-core.c
index 7e78931..b40b5d2 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2895,7 +2895,7 @@ EXPORT_SYMBOL_GPL(blk_rq_unprep_clone);
  static void __blk_rq_prep_clone(struct request *dst, struct request *src)
  {
  	dst->cpu = src->cpu;
-	dst->cmd_flags = (src->cmd_flags & REQ_CLONE_MASK) | REQ_NOMERGE;
+	dst->cmd_flags |= (src->cmd_flags & REQ_CLONE_MASK) | REQ_NOMERGE;
  	dst->cmd_type = src->cmd_type;
  	dst->__sector = blk_rq_pos(src);
  	dst->__data_len = blk_rq_bytes(src);