From: Damien Le Moal <dlemoal@kernel.org>
To: Bart Van Assche <bvanassche@acm.org>, Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Yu Kuai <yukuai1@huaweicloud.com>,
Ming Lei <ming.lei@redhat.com>,
Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Subject: Re: [PATCH 1/2] block: Make __submit_bio_noacct() preserve the bio submission order
Date: Sat, 24 May 2025 10:48:00 +0200 [thread overview]
Message-ID: <4128be53-b3be-48a5-8d53-9e0ef40c6d64@kernel.org> (raw)
In-Reply-To: <907cf988-372c-4535-a4a8-f68011b277a3@acm.org>
On 5/23/25 18:30, Bart Van Assche wrote:
> On 5/22/25 11:02 PM, Damien Le Moal wrote:
>> On 5/22/25 19:08, Bart Van Assche wrote:
> > [ ... ]
>> Which DM driver is it ? Does that DM driver have some special work queue
>> handling of BIO submissions ? Or does is simply remap the BIO and send it down
>> to the underlying device in the initial submit_bio() context ? If it is the
>> former case, then that DM driver must enable zone write plugging. If it is the
>> latter, it should not need zone write plugging and ordering will be handled
>> correctly throughout the submit_bio() context for the initial DM BIO, assuming
>> that the submitter does indeed serialize write BIO submissions to a zone. I have
>> not looked at f2fs code in ages. When I worked on it, there was a mutex to
>> serialize write issuing to avoid reordering issues...
>
> It is the dm-default-key driver, a driver about which everyone
> (including the authors of that driver) agree that it should disappear.
> Unfortunately the functionality provided by that driver has not yet been
> integrated in the upstream kernel (encrypt filesystem metadata).
>
> How that driver (dm-default-key) works is very similar to how dm-crypt
> works. I think that the most important difference is that dm-crypt
> requests encryption for all bios while dm-default-key only sets an
> encryption key for a subset of the bios it processes.
>
> The source code of that driver is available here:
> https://android.googlesource.com/kernel/common/+/refs/heads/android16-6.12/drivers/md/dm-default-key.c
Well, this is an out of tree driver. Not touching this.
Unless you can reproduce the issue with dm-crypt (or any other DM target that is
upstream), I will not even try to debug this.
Note that our internal test suite runs *lots* of different zoned devices (SMR
HDD, ZNS SSDs, nullblk, tcmu-runner ZBC device, scsi_debug, qemu nvme zns
device) against *lots* of configurations for file systems (xfs, btrfs, zonefs)
and DM targets (dm-crypt, dm-linear) and we have not seen any reordering issue,
We run this test suite weekly against RC kernels and for-next branch.
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2025-05-24 8:48 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-14 20:29 [PATCH 0/2] Two bug fixes for zoned block devices Bart Van Assche
2025-05-14 20:29 ` [PATCH 1/2] block: Make __submit_bio_noacct() preserve the bio submission order Bart Van Assche
2025-05-15 7:19 ` Niklas Cassel
2025-05-15 15:58 ` Bart Van Assche
2025-05-16 4:47 ` Christoph Hellwig
2025-05-19 22:12 ` Bart Van Assche
2025-05-20 13:56 ` Christoph Hellwig
2025-05-20 18:09 ` Bart Van Assche
2025-05-21 5:53 ` Christoph Hellwig
2025-05-21 21:18 ` Bart Van Assche
2025-05-22 5:12 ` Damien Le Moal
2025-05-22 17:08 ` Bart Van Assche
2025-05-23 6:02 ` Damien Le Moal
2025-05-23 16:30 ` Bart Van Assche
2025-05-24 8:48 ` Damien Le Moal [this message]
2025-05-24 14:05 ` Bart Van Assche
2025-05-24 15:36 ` Damien Le Moal
2025-05-26 5:24 ` Christoph Hellwig
2025-05-27 16:19 ` Bart Van Assche
2025-05-31 0:25 ` Bart Van Assche
2025-06-08 22:07 ` Bart Van Assche
2025-06-08 22:47 ` Damien Le Moal
2025-06-09 3:58 ` Christoph Hellwig
2025-06-09 20:48 ` Bart Van Assche
2025-06-10 5:04 ` Christoph Hellwig
2025-06-09 3:55 ` Christoph Hellwig
2025-06-10 17:23 ` Bart Van Assche
2025-06-10 23:18 ` Keith Busch
2025-06-11 0:46 ` Damien Le Moal
2025-06-11 1:00 ` Keith Busch
2025-06-11 1:02 ` Damien Le Moal
2025-06-11 1:08 ` Keith Busch
2025-06-11 1:34 ` Keith Busch
2025-06-11 3:40 ` Christoph Hellwig
2025-06-11 4:21 ` Eric Biggers
2025-06-11 16:15 ` Bart Van Assche
2025-06-11 18:15 ` Eric Biggers
2025-06-11 19:43 ` Bart Van Assche
2025-06-18 22:27 ` Bart Van Assche
2025-05-23 4:21 ` Christoph Hellwig
2025-05-14 20:29 ` [PATCH 2/2] block: Fix a deadlock related freezing zoned storage devices Bart Van Assche
2025-05-16 4:51 ` Christoph Hellwig
2025-05-19 22:22 ` Bart Van Assche
2025-05-20 13:57 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4128be53-b3be-48a5-8d53-9e0ef40c6d64@kernel.org \
--to=dlemoal@kernel.org \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=shinichiro.kawasaki@wdc.com \
--cc=yukuai1@huaweicloud.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox