block_bio_remap tracepoint keep tracks of remapping information of the @bio. IOW, if underlying disk remaps @bio to other disk, it could be tracked using the tracepoint in __generic_make_request() loop. However, blk_partition_remap() also modifies the information before the tracepoint so that the remapping chain could be diverged and this could make some potential userspace tools confused. Moving the tracepoint before blk_partition_remap() can help it. Signed-off-by: Namhyung Kim <namhyung@xxxxxxxxx> --- block/blk-core.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index 90e1ffdeb415..a60b46cc9da5 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -1494,6 +1494,9 @@ static inline void __generic_make_request(struct bio *bio) bio->bi_size)) goto end_io; + if (old_sector != -1) + trace_block_bio_remap(q, bio, old_dev, old_sector); + /* * If this device has partitions, remap block n * of partition p to block n+start(p) of the disk. @@ -1503,9 +1506,6 @@ static inline void __generic_make_request(struct bio *bio) if (bio_integrity_enabled(bio) && bio_integrity_prep(bio)) goto end_io; - if (old_sector != -1) - trace_block_bio_remap(q, bio, old_dev, old_sector); - old_sector = bio->bi_sector; old_dev = bio->bi_bdev->bd_dev; -- 1.7.6 -- 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
