Re: [GIT PULL] Asymmetric keys fix for v6.4-rc5

[Ard Biesheuvel]

On Mon, 5 Jun 2023 at 10:49, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, Jun 02, 2023 at 08:02:23PM -0400, Linus Torvalds wrote:
> >
> > I absolutely abhor the crypto interfaces. They all seem designed for
> > that "external DMA engine" case that seems so horrendously pointless
> > and slow.  In practice so few of them are that, and we have all those
> > optimized routines for doing it all on the CPU - but have in the
> > meantime wasted all that time and effort into copying everything,
> > turning simple buffers into sg-bufs etc etc. The amount of indirection
> > and "set this state in the state machine" is just nasty, and this
> > seems to all be a prime example of it all. With some of it then
> > randomly going through some kthread too.
>
> You're right.  Originally SG lists were used as the majority of
> our input came from network packets, in the form of skb's.  They
> are easily translated into SG lists.  This is still somewhat the
> case for parts of the Crypto API (e.g., skcipher and ahash).
>
> However, for akcipher the only user of the underlying API is the
> file in question so I absolutely agree that forcing it to go through
> an SG list is just wrong.
>
> I'll change the underlying akcipher interface to take pointers
> instead and hide the SG list stuff (along with the copying) inside
> API.
>

Could we do the same for the compression API? This is a major pain as
well, and results (on my 128-core workstation) in 32 MiB permanently
tied up in scratch buffers in the scomp-to-acomp adaptation layer
because most of the underlying implementations are compression
libraries operating on plain virtual addresses, and so the
scatterlists needs to be copied into a buffer and back to perform the
actual transformation.

The only user user of the async compression interface is zswap, but it
blocks on the completion so it is actually synchronous as well.