Re: [RFC PATCH 2/2] dm: don't try to split REQ_OP_ZONE_APPEND bios

On 2020/06/20 1:27, Mike Snitzer wrote:

On Fri, Jun 19 2020 at  3:54am -0400,
Damien Le Moal [off-list ref] wrote:

quoted

On 2020/06/19 15:59, Johannes Thumshirn wrote:

quoted

REQ_OP_ZONE_APPEND bios cannot be split so return EIO if we can't fit it
into one IO.

Signed-off-by: Johannes Thumshirn <redacted>
---
 drivers/md/dm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 058c34abe9d1..c720a7e3269a 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c

@@ -1609,6 +1609,9 @@ static int __split_and_process_non_flush(struct clone_info *ci)
 
 	len = min_t(sector_t, max_io_len(ci->sector, ti), ci->sector_count);
 
+	if (bio_op(ci->bio) == REQ_OP_ZONE_APPEND && len < ci->sector_count)
+		return -EIO;
+
 	r = __clone_and_map_data_bio(ci, ti, ci->sector, &len);
 	if (r < 0)
 		return r;

I think this is OK. The stacked max_zone_append_sectors limit should have
prevented that to happen  in the first place I think, but better safe than sorry.

Reviewed-by: Damien Le Moal <redacted>

If stacked max_zone_append_sectors limit should prevent it then I'd
rather not sprinkle more zoned specific checks in DM core.

Mike,

Just to be extra sure, I checked this again. Since for zoned block devices the
mapping of a target must be zoned aligned and a zone append command is always
fully contained within a zone, we do not need this check. The stacked limits and
submit_bio() code will fail a zone append command that is too large or that
spans zones before we get here.

That is of course assuming that the target does not expose zones that are mapped
using multiple chunks from different devices. There is currently no target doing
that, so this is OK. We can safely drop this patch.

Thanks.

Thanks,
Mike

-- 
Damien Le Moal
Western Digital Research