linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Vasily Gorbik <gor@linux.ibm.com>,
	linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	axboe@kernel.dk, hch@lst.de, martin.petersen@oracle.com,
	Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCHv4 6/8] crypto: add rocksoft 64b crc guard tag framework
Date: Thu, 10 Mar 2022 07:39:59 -0800	[thread overview]
Message-ID: <20220310153959.GB329710@dhcp-10-100-145-180.wdc.com> (raw)
In-Reply-To: <YikEs7RNgPXTQolv@gmail.com>

On Wed, Mar 09, 2022 at 07:49:07PM +0000, Eric Biggers wrote:
> The issue is that every other "shash" algorithm besides crct10dif, including
> crc32 and crc32c, follow the convention of treating the digest as bytes.  Doing
> otherwise is unusual for the crypto API.  So I have a slight preference for
> treating it as bytes.  Perhaps see what Herbert Xu (maintainer of the crypto
> API, Cc'ed) recommends?

I'm okay either way, they're both simple enough. Here is an update atop
this series to match the other shash conventions if this is preferred
over my previous fix:

---
diff --git a/block/t10-pi.c b/block/t10-pi.c
index 914d8cddd43a..f9eb45571bc7 100644
--- a/block/t10-pi.c
+++ b/block/t10-pi.c
@@ -282,7 +282,7 @@ EXPORT_SYMBOL(t10_pi_type3_ip);
 
 static __be64 ext_pi_crc64(void *data, unsigned int len)
 {
-	return cpu_to_be64(crc64_rocksoft(data, len));
+	return cpu_to_be64(le64_to_cpu(crc64_rocksoft(data, len)));
 }
 
 static blk_status_t ext_pi_crc64_generate(struct blk_integrity_iter *iter,
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index f1a22794c404..f9e5f601c657 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -3686,11 +3686,11 @@ static const struct hash_testvec crc64_rocksoft_tv_template[] = {
 	{
 		.plaintext	= zeroes,
 		.psize		= 4096,
-		.digest		= (u8 *)(u64[]){ 0x6482d367eb22b64eull },
+		.digest		= "\x4e\xb6\x22\xeb\x67\xd3\x82\x64",
 	}, {
 		.plaintext	= ones,
 		.psize		= 4096,
-		.digest		= (u8 *)(u64[]){ 0xc0ddba7302eca3acull },
+		.digest		= "\xac\xa3\xec\x02\x73\xba\xdd\xc0",
 	}
 };
 
diff --git a/include/linux/crc64.h b/include/linux/crc64.h
index e044c60d1e61..5319f9a9fc19 100644
--- a/include/linux/crc64.h
+++ b/include/linux/crc64.h
@@ -12,7 +12,7 @@
 u64 __pure crc64_be(u64 crc, const void *p, size_t len);
 u64 __pure crc64_rocksoft_generic(u64 crc, const void *p, size_t len);
 
-u64 crc64_rocksoft(const unsigned char *buffer, size_t len);
-u64 crc64_rocksoft_update(u64 crc, const unsigned char *buffer, size_t len);
+__le64 crc64_rocksoft(const unsigned char *buffer, size_t len);
+__le64 crc64_rocksoft_update(u64 crc, const unsigned char *buffer, size_t len);
 
 #endif /* _LINUX_CRC64_H */
diff --git a/lib/crc64-rocksoft.c b/lib/crc64-rocksoft.c
index fc9ae0da5df7..215acb79a15d 100644
--- a/lib/crc64-rocksoft.c
+++ b/lib/crc64-rocksoft.c
@@ -54,16 +54,16 @@ static struct notifier_block crc64_rocksoft_nb = {
 	.notifier_call = crc64_rocksoft_notify,
 };
 
-u64 crc64_rocksoft_update(u64 crc, const unsigned char *buffer, size_t len)
+__le64 crc64_rocksoft_update(u64 crc, const unsigned char *buffer, size_t len)
 {
 	struct {
 		struct shash_desc shash;
-		u64 crc;
+		__le64 crc;
 	} desc;
 	int err;
 
 	if (static_branch_unlikely(&crc64_rocksoft_fallback))
-		return crc64_rocksoft_generic(crc, buffer, len);
+		return cpu_to_le64(crc64_rocksoft_generic(crc, buffer, len));
 
 	rcu_read_lock();
 	desc.shash.tfm = rcu_dereference(crc64_rocksoft_tfm);
@@ -77,7 +77,7 @@ u64 crc64_rocksoft_update(u64 crc, const unsigned char *buffer, size_t len)
 }
 EXPORT_SYMBOL_GPL(crc64_rocksoft_update);
 
-u64 crc64_rocksoft(const unsigned char *buffer, size_t len)
+__le64 crc64_rocksoft(const unsigned char *buffer, size_t len)
 {
 	return crc64_rocksoft_update(0, buffer, len);
 }
--

  reply	other threads:[~2022-03-10 15:40 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-03 20:13 [PATCHv4 0/8] 64-bit data integrity field support Keith Busch
2022-03-03 20:13 ` [PATCHv4 1/8] block: support pi with extended metadata Keith Busch
2022-03-03 20:13 ` [PATCHv4 2/8] nvme: allow integrity on extended metadata formats Keith Busch
2022-03-03 20:13 ` [PATCHv4 3/8] asm-generic: introduce be48 unaligned accessors Keith Busch
2022-03-03 20:47   ` Bart Van Assche
2022-03-04  1:31   ` David Laight
2022-03-04  2:40     ` Martin K. Petersen
2022-03-04  2:56     ` Keith Busch
2022-03-03 20:13 ` [PATCHv4 4/8] linux/kernel: introduce lower_48_bits function Keith Busch
2022-03-03 20:48   ` Bart Van Assche
2022-03-03 20:13 ` [PATCHv4 5/8] lib: add rocksoft model crc64 Keith Busch
2022-03-04  2:41   ` Martin K. Petersen
2022-03-04  7:53   ` David Laight
2022-03-04 15:02     ` Keith Busch
2022-03-03 20:13 ` [PATCHv4 6/8] crypto: add rocksoft 64b crc guard tag framework Keith Busch
2022-03-08 20:21   ` Vasily Gorbik
2022-03-08 20:27     ` Keith Busch
2022-03-08 21:46       ` Keith Busch
2022-03-08 22:03         ` Vasily Gorbik
2022-03-09  4:57       ` Eric Biggers
2022-03-09 19:31         ` Keith Busch
2022-03-09 19:49           ` Eric Biggers
2022-03-10 15:39             ` Keith Busch [this message]
2022-03-10 18:36               ` Eric Biggers
2022-03-11 20:00                 ` Keith Busch
2022-03-03 20:13 ` [PATCHv4 7/8] block: add pi for extended integrity Keith Busch
2022-03-04  2:41   ` Martin K. Petersen
2022-03-03 20:13 ` [PATCHv4 8/8] nvme: add support for enhanced metadata Keith Busch
2022-03-04  2:38   ` Martin K. Petersen
2022-03-07 19:34 ` [PATCHv4 0/8] 64-bit data integrity field support Keith Busch
2022-03-07 19:50   ` Jens Axboe
2022-03-07 19:50 ` Jens Axboe

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=20220310153959.GB329710@dhcp-10-100-145-180.wdc.com \
    --to=kbusch@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=ebiggers@kernel.org \
    --cc=gor@linux.ibm.com \
    --cc=hch@lst.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=martin.petersen@oracle.com \
    /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;
as well as URLs for NNTP newsgroup(s).