mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Josef Schlehofer <pepe.schlehofer@gmail.com>,
	Mikulas Patocka <mpatocka@redhat.com>
Cc: Alasdair Kergon <agk@redhat.com>,
	Mike Snitzer <snitzer@kernel.org>,
	Benjamin Marzinski <bmarzins@redhat.com>,
	dm-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Ignat Korchagin <ignat@linux.win>,
	Milan Broz <gmazyland@gmail.com>
Subject: Re: [PATCH] dm-crypt: defer async write submission to write thread
Date: Wed, 11 Nov 2026 17:56:18 +0900	[thread overview]
Message-ID: <b0108ede-001a-4747-b8a4-f39094083122@kernel.org> (raw)
In-Reply-To: <20261110042809.62987-1-pepe.schlehofer@gmail.com>

On 2026/11/10 13:29, Josef Schlehofer wrote:
> On Mon, 9 Nov 2026, Mikulas Patocka wrote:
>> On Mon, 9 Nov 2026, Damien Le Moal wrote:
>>> Originally, this was added to avoid write reordering for zoned block devices.
>>> So did you test this change with that (scsi_debug or null-blk) ? You can also
>>> use an emulated NVMe ZNS device in QEMU.
>>
>> So, should we disable asynchronous crypto operations for zoned devices?
> 
> I tested dm-7.4 with and without the patch in QEMU, using null_blk,
> scsi_debug and an emulated ZNS device. I tested both cryptd and a
> synchronous cipher.
> 
> My write and read-back checks passed on both arm64 and x86_64. I also
> ran fio's t/zbd suite and blktests zbd on arm64. All tests passed with
> both kernels.

My bad. Since we switched the block layer to zone write plugging, a DM device
only ever sees a single write command per zone. So regardless of what the target
driver does with that command, things are fine for writes to zoned block
devices. The only gotcha here is that if the target driver splits the write,
then the fragments must be ordered correctly to be sequential. If I remember
correctly, I patched dm-crypt to avoid such splitting for exactly that reason.

> 
> I also used a kprobe to check whether async=1 was ever used in
> kcryptd_crypt_write_io_submit() on zoned devices. It wasn't, since
> DM_CRYPT_WRITE_INLINE keeps those writes on the async=0 path.
> 
> The only exception was blktests zbd/013, which stalled during cleanup on
> both kernels under heavy host load. The LUKS volume was still mapped
> after luksClose, causing null_blk unloading to wait.
> 
> I couldn't find any issues with this change or with async crypto on
> zoned devices, so whether to disable it is up to you and Damien.

Thanks for checking. async is fine for zoned devices. Feel free to focus on
other comments that mention that this may enable async even if the user does not
want that.

-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2026-11-11  8:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05  7:27 Josef Schlehofer
2026-11-09  6:08 ` Damien Le Moal
2026-11-09 12:18   ` Mikulas Patocka
2026-11-10  4:29     ` Josef Schlehofer
2026-11-11  8:56       ` Damien Le Moal [this message]
2026-11-09 20:51 ` Ignat Korchagin

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=b0108ede-001a-4747-b8a4-f39094083122@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=agk@redhat.com \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=gmazyland@gmail.com \
    --cc=ignat@linux.win \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=pepe.schlehofer@gmail.com \
    --cc=snitzer@kernel.org \
    --cc=stable@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®