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

Damien Le Moal Damien.LeMoal at wdc.com
Mon Jun 22 00:27:34 UTC 2020


On 2020/06/20 1:27, Mike Snitzer wrote:
> On Fri, Jun 19 2020 at  3:54am -0400,
> Damien Le Moal <Damien.LeMoal at wdc.com> 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 <johannes.thumshirn at wdc.com>
>>> ---
>>>  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 <damien.lemoal at wdc.com>
> 
> 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






More information about the dm-devel mailing list