On 2020/06/20 1:27, Mike Snitzer wrote: > On Fri, Jun 19 2020 at 3:54am -0400, > Damien Le Moal <[email protected]> wrote: > >> On 2020/06/19 15:59, Johannes Thumshirn wrote: >>> 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 <[email protected]> >>> --- >>> 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 <[email protected]> > > 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 -- dm-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/dm-devel
