Re: [PATCH] nvmet-tcp: switch to using the crc32c library

From: Hannes Reinecke
Date: Thu Feb 27 2025 - 02:26:24 EST


On 2/26/25 20:01, Eric Biggers wrote:
On Wed, Feb 26, 2025 at 10:37:55AM +0100, Hannes Reinecke wrote:
... and it also eliminates a sporadic crash which we've seen
where 'snd_hash' wasn't initialized when sending PDUs.
Thanks for doing this!

I'm not sure how that could have happened, since the ahash was allocated when
'if (queue->hdr_digest || queue->data_digest)' which seemed to match the
conditions for when it was used. But yeah, it's certainly nice to not have the
pointless allocation to worry about.

(Note to self: check the nvme-tls code for crc32c usage ...)

I have patches for nvme-tls almost ready too. Just been taking my time since
I've been updating all other users of "crc32" and "crc32c" in the kernel too.
And I need to decide what to do about skb_copy_and_hash_datagram_iter().

If it were me I would _love_ to switch the nvme-tcp recv patch over to recvmsg and kill the ->read_sock() implementation.
->read_sock uses a completely different codepath in tls_sw, and nvme is
the only user of that. So there's a fair chance that we might miss any
improvements or fixes.

Plus we currently have no good way of handling TLS records from ->read_sock(), which is something we might want to do in the future.

So if we had an equivalent for skb_copy_and_hash_iter() for recvmsg()
I could revisit my original patchset and work on getting ->read_sock()
replaced.

Cheers,

Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich