On 4/14/25 10:19 PM, Mikulas Patocka wrote:
>
>
> On Fri, 11 Apr 2025, Damien Le Moal wrote:
>
>> When a dm-delay device is being suspended, the .presuspend() operation
>> is first executed (delay_presuspend()) to immediately issue all the BIOs
>> present in the delayed list of the device and also sets the device
>> may_delay boolean to false. At the same time, if any new BIO is issued
>> to the device will not be delayed and immediately issued with
>> delay_bio() returning DM_MAPIO_REMAPPED. This creates a situation where
>> potentially 2 different contexts may be issuing write BIOs to the same
>> zone of a zone device without respecting the issuing order from the
>> user, that is, a newly issued write BIO may be issued before other write
>> BIOs for the same target zone that are in the device delayed list. If
>> such situation occurs, write BIOs may be failed by the underlying zoned
>> device due to an unaligned write error.
>>
>> Prevent this situation from happening by always handling newly issued
>> write BIOs using the delayed list of BIOs, even when the device is being
>> suspended. This is done by forcing the use of the worker kthread for
>> zoned devices, and by modifying flush_worker_fn() to always flush all
>> delayed BIOs if the device may_delay boolean is false.
>>
>> Reported-by: Benjamin Marzinski <bmarz...@redhat.com>
>> Fixes: d43929ef65a6 ("dm-delay: support zoned devices")
>> Signed-off-by: Damien Le Moal <dlem...@kernel.org>
>> ---
>> Changes from v1:
>> - Fixed typo in commit message
>> - Added reported-by tag
>>
>> drivers/md/dm-delay.c | 29 +++++++++++++++++++++--------
>> 1 file changed, 21 insertions(+), 8 deletions(-)
>
> Hi
>
> I looked at the generic device mapper code and it seems that ordering of
> write bios is not guaranteed with any target in case of suspend/resume.
>
> * we suspend the device:
> * received bios are added to md->deferred in queue_io
>
> * we resume the device:
> * __dm_resume calls dm_queue_flush
> * dm_queue_flush clears DMF_BLOCK_IO_FOR_SUSPEND and submits work item
> &md->work (dm_wq_work)
> * dm_resume clears DMF_SUSPENDED
> * the device starts accepting new bios in dm_submit_bio
> * dm_wq_work runs concurrently with new bios that are received, so
> ordering of bios is not preserved
>
> So it doesn't make much sense to try to fix it in dm-delay, if it isn't
> supposed to work at all.
Just need to fix the generic DM resume code then. This patch fixing dm-delay is
still relevant even with DM generic resume fixes.
I can resend the dm-delay fix together with DM core resume fixes. And Benjamin
can re-send the dm-delay kthread timer cleanup independently (I will rebase) or
on top of that fix series. Does that work for you ?
>
> Mikulas
>
--
Damien Le Moal
Western Digital Research
