rq->rq_disk and bio->bi_bdev->bd_disk may differ if a request has passed through remapping drivers. FSEQ_DATA request incorrectly followed bio->bi_bdev->bd_disk ending up being issued w/ mismatching rq_disk. Make it follow orig_rq->rq_disk. Signed-off-by: Tejun Heo <tj@xxxxxxxxxx> Reported-by: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx> --- Kiyoshi, can you please apply this patch on top and verify that the problem goes away? The reason I and Mike didn't see the problem was because we were using REQ_FUA capable underlying device, which makes block layer bypass sequencing for FSEQ_DATA request. Thanks. block/blk-flush.c | 7 +++++++ 1 file changed, 7 insertions(+) Index: block/block/blk-flush.c =================================================================== --- block.orig/block/blk-flush.c +++ block/block/blk-flush.c @@ -111,6 +111,13 @@ static struct request *queue_next_fseq(s break; case QUEUE_FSEQ_DATA: init_request_from_bio(rq, orig_rq->bio); + /* + * orig_rq->rq_disk may be different from + * bio->bi_bdev->bd_disk if orig_rq got here through + * remapping drivers. Make sure rq->rq_disk points + * to the same one as orig_rq. + */ + rq->rq_disk = orig_rq->rq_disk; rq->cmd_flags &= ~(REQ_FLUSH | REQ_FUA); rq->cmd_flags |= orig_rq->cmd_flags & (REQ_FLUSH | REQ_FUA); rq->end_io = flush_data_end_io; -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
