From: Harald Freudenberger <freude@linux.ibm.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: dengler@linux.ibm.com, ifranzki@linux.ibm.com, agk@redhat.com,
snitzer@kernel.org, linux-s390@vger.kernel.org,
dm-devel@lists.linux.dev, herbert@gondor.apana.org.au,
Milan Broz <gmazyland@gmail.com>
Subject: Re: [PATCH v4 2/2] dm-integrity: introduce ahash support for the internal hash
Date: Fri, 14 Feb 2025 10:43:32 +0100 [thread overview]
Message-ID: <bd809181069f87626c0bb5d41695600d@linux.ibm.com> (raw)
In-Reply-To: <50a28342-9d3c-b4e4-de13-40304eabb8b1@redhat.com>
On 2025-02-05 21:23, Mikulas Patocka wrote:
> Introduce ahash support for the "internal hash" algorithm.
>
> Rework the dm-integrity code to be able to run the "internal hash"
> either with a synchronous ("shash") or asynchronous ("ahash") hash
> algorithm implementation.
>
> The get_mac() function now tries to decide which of the digest
> implemenations to use if there is a choice:
> - If an ahash and shash tfm is available and both are backed by the
> same driver name it is assumed that the shash is the faster
> implementation and thus the shash tfm is delivered to the caller.
> - If an ahash and shash tfm is available but the backing device driver
> divers (different driver names) it is assumed that the ahash
> implementation is a "better" hardware based implementation and thus
> the ahash tfm is delivered to the caller.
> - If there is no choice, for example only an ahash or an shash
> implementation is available then this tfm is delivered to the
> caller. Especially in cases where only an ahash implementation is
> available this is now used instead of failing.
> - The caller can steer this choice by passing a NULL to the ahash or
> shash parameter, thus enforcing to only allocate an algorithm of the
> remaining possibility.
>
> The function integrity_sector_checksum() is now only a dispatcher
> function calling one of the two new functions
> integrity_ahash_sector_checksum() or integrity_shash_sector_checksum()
> based on which tfm is allocated based on the two new fields
> internal_shash and internal_ahash in struct dm_integrity_c.
>
> Together with this comes some slight rework around availability and
> digest size of the internal hash in use.
>
> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> ---
> drivers/md/dm-integrity.c | 350
> +++++++++++++++++++++++++++++++++-------------
> 1 file changed, 252 insertions(+), 98 deletions(-)
>
> Index: linux-2.6/drivers/md/dm-integrity.c
> ===================================================================
...
> static struct target_type integrity_target = {
> .name = "integrity",
> - .version = {1, 13, 0},
> + .version = {1, 14, 0},
> .module = THIS_MODULE,
> .features = DM_TARGET_SINGLETON | DM_TARGET_INTEGRITY,
> .ctr = dm_integrity_ctr,
Mikulas, I am still working.
All the straight forward tests where successful. Even my new phma-shaxxx
was running fine. The integrity-compat-test also found no issues.
However, as you wrote, I enforced using ahashes in get_mac() and
catched some weird kernel crashes but had no time to investigate
further.
I'll continue on this as soon I have some spare time and will report
the results.
kind regards
Harald Freudenberger
next prev parent reply other threads:[~2025-02-14 9:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-05 20:23 [PATCH v4 2/2] dm-integrity: introduce ahash support for the internal hash Mikulas Patocka
2025-02-05 21:24 ` Eric Biggers
2025-02-06 15:22 ` Harald Freudenberger
2025-02-14 9:43 ` Harald Freudenberger [this message]
2025-07-17 15:18 ` Harald Freudenberger
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=bd809181069f87626c0bb5d41695600d@linux.ibm.com \
--to=freude@linux.ibm.com \
--cc=agk@redhat.com \
--cc=dengler@linux.ibm.com \
--cc=dm-devel@lists.linux.dev \
--cc=gmazyland@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=ifranzki@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=snitzer@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 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.