Re: [PATCH net-next v2 2/5] net/tcp-ao: Use crypto library API instead of crypto_ahash

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Apr 28, 2026 at 02:24:45AM +0100, David Laight wrote:
> On Mon, 27 Apr 2026 10:27:24 -0700
> Eric Biggers <ebiggers@kernel.org> wrote:
> 
> > Currently the kernel's TCP-AO implementation does the MAC and KDF
> > computations using the crypto_ahash API.  This API is inefficient and
> > difficult to use, and it has required extensive workarounds in the form
> > of per-CPU preallocated objects (tcp_sigpool) to work at all.
> > 
> > Let's use lib/crypto/ instead.  This means switching to straightforward
> > stack-allocated structures, virtually addressed buffers, and direct
> > function calls.  It also means removing quite a bit of error handling.
> > This makes TCP-AO quite a bit faster.
> > 
> > This also enables many additional cleanups, which later commits will
> > handle: removing tcp-sigpool, removing support for crypto_tfm cloning,
> > removing more error handling, and replacing more dynamically-allocated
> > buffers with stack buffers based on the now-statically-known limits.
> > 
> > Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> > Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ...
> > @@ -344,33 +444,26 @@ static int tcp_v4_ao_calc_key(struct tcp_ao_key *mkt, u8 *key,
> >  	struct kdf_input_block {
> >  		u8                      counter;
> >  		u8                      label[6];
> >  		struct tcp4_ao_context	ctx;
> >  		__be16                  outlen;
> > -	} __packed * tmp;
> 
> That looks a bit horrid.
> I also had a feeling that the compiler sometimes rejects non-packed structures
> inside packed ones.
> Perhaps nest the whole thing inside another structure that has an initial
> u8 pad and is marked __packed __aligned(4).
> Then the assignments to the fields of 'ctx' will be known to be aligned
> even when tcp4_ao_context is also __packed.
> 
> 	David

This series doesn't change the definition of struct kdf_input_block.
Could we defer changing it (if it makes sense to) to a later patch?
Yes, there might be a way to get the be32 and be16 fields naturally
aligned and get the compiler to understand that.  But that would be a
pretty small micro-optimization compared to removing all the tcp_sigpool
overhead from the same function (which this series does).

- Eric