On Thu, Feb 14 2019 at 4:19am -0500,
yangerkun <yangerkun@xxxxxxxxxx> wrote:
> Since 57c36519e4("dm: fix clone_bio() to trigger blk_recount_segments()")
> has been reverted by fa8db494("dm: don't use bio_trim() afterall"), the
> problem that clone bio won't trigger blk_recount_segments will exits
> again. So just clean the flag in clone_bio.
>
> Fixes: fa8db4948f522("dm: don't use bio_trim() afterall")
> Signed-off-by: yangerkun <yangerkun@xxxxxxxxxx>
> ---
> drivers/md/dm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> index 515e6af..b22ac04 100644
> --- a/drivers/md/dm.c
> +++ b/drivers/md/dm.c
> @@ -1336,6 +1336,7 @@ static int clone_bio(struct dm_target_io *tio, struct bio *bio,
> return r;
> }
>
> + bio_clear_flag(clone, BIO_SEG_VALID);
> bio_advance(clone, to_bytes(sector - clone->bi_iter.bi_sector));
> clone->bi_iter.bi_size = to_bytes(len);
>
> --
> 2.9.5
>
Yes, when I wrote commit fa8db4948f522 I purposely did _not_ clear
BIO_SEG_VALID. Commit 57c36519e4 wasn't born out of an observed need to
blk_recount_segments() (e.g. otherwise something would fail).
So I just reverted to what DM has done in clone_bio() for quite a long
time once using bio_trim() became a liability (since fixed in dm-crypt,
but not staged upstream yet).
Anyway: I'm open to reconsidering, by taking your patch, if there is a
genuine benefit/fix associated with triggering blk_recount_segments()
for clones. I'm unaware of why it's needed...
Mike
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
