All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mohamad Raizudeen <raizudeen.kerneldev@gmail.com>
To: Simon Richter <Simon.Richter@hogyros.de>
Cc: ebiggers@kernel.org, ardb@kernel.org, Jason@zx2c4.com,
	skhan@linuxfoundation.org, me@brighamcampbell.com,
	jkoolstra@xs4all.nl, linux-crypto@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] lib/crypto: sha1: use put_unaligned_be64() for length encoding
Date: Sun, 11 Oct 2026 14:44:09 +0530	[thread overview]
Message-ID: <astTYX3RBV44n2gX@kernel> (raw)
In-Reply-To: <454f2204-2c4b-43c0-8fd0-1eaa83186e69@hogyros.de>

On Sun, Oct 11, 2026 at 03:10:44PM +0900, Simon Richter wrote:
> Hi,
> 
> On 10/11/26 14:15, Mohamad Raizudeen wrote:
> 
> > The rest of this file already uses the unaligned access helpers like
> > get_unaligned_be32() for reading input and put_unaligned_be32() for writing
> > the digest, for all structured buffer accesses. Replace both casts with
> > put_unaligned_be64() for consistency.
> 
> These aren't unaligned accesses, though.
> 
> > In hmac_sha1_final(), this also writes the full 64-bit length field
> > explicitly rather than writing only 32 bits and relying on a preceding
> > memset() to zero the upper 32 bits. The resulting bytes are identical,
> > nothing changes functionally.
> 
> These aren't unaligned either, and the size here is fixed (which is also why
> we don't need to handle the case where the size does not fit into the
> current block).
> 
> The get_unaligned and put_unaligned functions aren't used as convenience
> functions, but because the data might actually be unaligned, so we need to
> eat the cost of doing an unaligned access.
> 
>    Simon

Hi,

Well, you are right. My patch would have added unnecessary overhead on
strict alignment architectures.

Withdrawing this patch.

Thanks,
Mohamad Raizudeen

      reply	other threads:[~2026-10-11  9:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-11  5:15 [PATCH] lib/crypto: sha1: use put_unaligned_be64() for length encoding Mohamad Raizudeen
2026-10-11  6:10 ` Simon Richter
2026-10-11  9:14   ` Mohamad Raizudeen [this message]

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=astTYX3RBV44n2gX@kernel \
    --to=raizudeen.kerneldev@gmail.com \
    --cc=Jason@zx2c4.com \
    --cc=Simon.Richter@hogyros.de \
    --cc=ardb@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=jkoolstra@xs4all.nl \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@brighamcampbell.com \
    --cc=skhan@linuxfoundation.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.