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);
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
