All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Yureka <yuka@yuka.dev>
Cc: regressions@lists.linux.dev,
	Boris Brezillon <bbrezillon@kernel.org>,
	Arnaud Ebalard <arno@natisbad.org>,
	Srujana Challa <schalla@marvell.com>,
	dm-devel@redhat.com, Mikulas Patocka <mpatocka@redhat.com>,
	linux-crypto@vger.kernel.org
Subject: Re: [dm-devel] [REGRESSION] dm_crypt essiv ciphers do not use async driver mv-aes-cbc anymore
Date: Fri, 29 Sep 2023 22:43:27 +0000	[thread overview]
Message-ID: <20230929224327.GA11839@google.com> (raw)
In-Reply-To: <53f57de2-ef58-4855-bb3c-f0d54472dc4d@yuka.dev>

Hi Yureka,

On Fri, Sep 29, 2023 at 11:08:55PM +0200, Yureka wrote:
> #regzbot introduced: 7bcb2c99f8ed
> 
> I am running the NixOS distribution cross-compiled from x86_64 to a Marvell
> Armada 388 armv7 SoC.
> 
> I am not getting expected speeds when reading/writing on my encrypted hard
> drive with 6.5.5, while it is fast on 5.4.257. Volume is formatted like this:
> `cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/sda`.
> 
> Specifically, I tracked this down to the changes to crypto/essiv.c from
> 7bcb2c99f8ed mentioned above. Reverting those changes on top of a 6.5.5 kernel
> provides working (see applicable diff further below).
> 
> I'm *guessing* that this is related to the mv-aes-cbc crypto driver (from the
> marvell-cesa module) being registered as async (according to /proc/crypto),
> and I *suspect* that async drivers are not being used anymore by essiv or
> dm_crypt. Going by the commit description, which sounds more like a refactor,
> this does not seem intentional.

This is actually from commit b8aa7dc5c753 ("crypto: drivers - set the flag
CRYPTO_ALG_ALLOCATES_MEMORY"), which set CRYPTO_ALG_ALLOCATES_MEMORY in
marvell-cesa.  7bcb2c99f8ed is just one of the prerequisite commits.

I understand that the dm-crypt developers did this as an intentional bug fix in
order to prevent dm-crypt from using crypto drivers that are known to cause
deadlocks due to allocating memory during requests.

If you are interested in still being able to use marvell-cesa with dm-crypt, I
believe it would need to be fixed to meet the requirements for not needing
CRYPTO_ALG_ALLOCATES_MEMORY.  I've Cc'ed the maintainers of that driver.

#regzbot introduced: b8aa7dc5c753

- Eric

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Yureka <yuka@yuka.dev>
Cc: linux-crypto@vger.kernel.org, regressions@lists.linux.dev,
	Mikulas Patocka <mpatocka@redhat.com>,
	dm-devel@redhat.com, Boris Brezillon <bbrezillon@kernel.org>,
	Arnaud Ebalard <arno@natisbad.org>,
	Srujana Challa <schalla@marvell.com>
Subject: Re: [REGRESSION] dm_crypt essiv ciphers do not use async driver mv-aes-cbc anymore
Date: Fri, 29 Sep 2023 22:43:27 +0000	[thread overview]
Message-ID: <20230929224327.GA11839@google.com> (raw)
In-Reply-To: <53f57de2-ef58-4855-bb3c-f0d54472dc4d@yuka.dev>

Hi Yureka,

On Fri, Sep 29, 2023 at 11:08:55PM +0200, Yureka wrote:
> #regzbot introduced: 7bcb2c99f8ed
> 
> I am running the NixOS distribution cross-compiled from x86_64 to a Marvell
> Armada 388 armv7 SoC.
> 
> I am not getting expected speeds when reading/writing on my encrypted hard
> drive with 6.5.5, while it is fast on 5.4.257. Volume is formatted like this:
> `cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/sda`.
> 
> Specifically, I tracked this down to the changes to crypto/essiv.c from
> 7bcb2c99f8ed mentioned above. Reverting those changes on top of a 6.5.5 kernel
> provides working (see applicable diff further below).
> 
> I'm *guessing* that this is related to the mv-aes-cbc crypto driver (from the
> marvell-cesa module) being registered as async (according to /proc/crypto),
> and I *suspect* that async drivers are not being used anymore by essiv or
> dm_crypt. Going by the commit description, which sounds more like a refactor,
> this does not seem intentional.

This is actually from commit b8aa7dc5c753 ("crypto: drivers - set the flag
CRYPTO_ALG_ALLOCATES_MEMORY"), which set CRYPTO_ALG_ALLOCATES_MEMORY in
marvell-cesa.  7bcb2c99f8ed is just one of the prerequisite commits.

I understand that the dm-crypt developers did this as an intentional bug fix in
order to prevent dm-crypt from using crypto drivers that are known to cause
deadlocks due to allocating memory during requests.

If you are interested in still being able to use marvell-cesa with dm-crypt, I
believe it would need to be fixed to meet the requirements for not needing
CRYPTO_ALG_ALLOCATES_MEMORY.  I've Cc'ed the maintainers of that driver.

#regzbot introduced: b8aa7dc5c753

- Eric

  reply	other threads:[~2023-09-29 22:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-29 21:08 [REGRESSION] dm_crypt essiv ciphers do not use async driver mv-aes-cbc anymore Yureka
2023-09-29 22:43 ` Eric Biggers [this message]
2023-09-29 22:43   ` Eric Biggers
2023-11-01 12:04   ` Linux regression tracking (Thorsten Leemhuis)
2023-11-01 12:04     ` Linux regression tracking (Thorsten Leemhuis)
2023-11-01 12:47     ` Mikulas Patocka
2023-11-01 12:47       ` Mikulas Patocka
2023-11-11 11:58       ` Thorsten Leemhuis

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=20230929224327.GA11839@google.com \
    --to=ebiggers@kernel.org \
    --cc=arno@natisbad.org \
    --cc=bbrezillon@kernel.org \
    --cc=dm-devel@redhat.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=regressions@lists.linux.dev \
    --cc=schalla@marvell.com \
    --cc=yuka@yuka.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.