On 05/11/2025 15:00, Mikulas Patocka wrote:
On Wed, 5 Nov 2025, John Garry wrote:
This small series enables atomic writes support for dm-crypt.
Apart from setting DM_TARGET_ATOMIC_WRITES flag, we need to make the
following changes:
- limit atomic write size to dm-crypt max write size
- BUG_ON() any partial completions for when REQ_ATOMIC is set
John Garry (2):
dm: BUG on REQ_ATOMIC in dm_accept_partial_bio()
dm-crypt: enable DM_TARGET_ATOMIC_WRITES
drivers/md/dm-crypt.c | 21 +++++++++++++++++++--
drivers/md/dm.c | 5 +++--
2 files changed, 22 insertions(+), 4 deletions(-)
--
2.43.5
Hi Mikulas,
Thanks for the patches, I reworked them a bit.
Regarding the first patch - note that the device mapper stack may be
arbitrarily reconfigured, so it is possible that REQ_ATOMIC bio may be
sent to a target that doesn't support atomic writes - and this could
trigger the "BUG_ON(bio->bi_opf & REQ_ATOMIC);".
When reconfigured, the dm device request queue limits are re-evaluated,
right?
So, we need to reject atomic bios to targets that don't support them.
Regarding the second patch - max_write_size and
DM_CRYPT_DEFAULT_MAX_WRITE_SIZE is a performance hint that may be set
arbitrarily by the user (it was added after we discovered that too long
bios would not paralellize compression/decompression and it caused
performance regression) - so it shouldn't restrict the size of atomic
bios.
oh, if it's a performance hint, then we can avoid splitting for atomic
writes.
The size of atomic bios should be restricted to "BIO_MAX_VECS <<
PAGE_SHIFT" - that is the hard limit.
dm-crypt already has logic to not split writes if ti->emulate_zone_append
is true - so I joined this logic with the REQ_ATOMIC logic.
I'll send updated patches, please test them.
Thanks,
John
