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
Earlier emails in this thread show that the bio splitting below the dm
driver can cause bio reordering. See also the call stack that is
available here:
https://lore.kernel.org/linux-block/47b24ea0-ef8f-441f-b405-a062b986ce93@xxxxxxx/
I asked for clarification in the first place because I still do not understand
what is going on reading that lightly explained backtrace you show in that
email. A more detailed time flow explanation of what is happening and in which
context would very likely clarify exactly what is gong on.
So far, the only thing I can think of is that maybe we need to split BIOs in DM
core before submitting them to the DM driver. But I am reluctant to send such
patch because I cannot justify/expalin its need based on your explanations.
Backtraces do not fully explain what happens because a single function
(__submit_bio_noacct()) processes bios for multiple levels in a stacked
block driver hierarchy. That's why I added debug code that reports the
disk name (sde) for the first bio that is inserted out-of-order. This
output shows that the bio reordering is the result of bio splitting at
the bottom of the stack.
Thanks,
Bart.
