linux-kernel - Re: [PATCH v11 00/24] zswap compression batching with optimized iaa

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aJ7FSUdvxtZyiHBq@gondor.apana.org.au>
Date: Fri, 15 Aug 2025 13:27:37 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Nhat Pham <nphamcs@...il.com>
Cc: Kanchana P Sridhar <kanchana.p.sridhar@...el.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	hannes@...xchg.org, yosry.ahmed@...ux.dev, chengming.zhou@...ux.dev,
	usamaarif642@...il.com, ryan.roberts@....com, 21cnbao@...il.com,
	ying.huang@...ux.alibaba.com, akpm@...ux-foundation.org,
	senozhatsky@...omium.org, linux-crypto@...r.kernel.org,
	davem@...emloft.net, clabbe@...libre.com, ardb@...nel.org,
	ebiggers@...gle.com, surenb@...gle.com, kristen.c.accardi@...el.com,
	vinicius.gomes@...el.com, wajdi.k.feghali@...el.com,
	vinodh.gopal@...el.com
Subject: Re: [PATCH v11 00/24] zswap compression batching with optimized
 iaa_crypto driver

On Fri, Aug 08, 2025 at 04:51:14PM -0700, Nhat Pham wrote:
> 
> Can we get some comments from crypto tree maintainers as well? I feel
> like this patch series is more crypto patch than zswap patch, at this
> point.
> 
> Can we land any zswap parts without the crypto API change? Grasping at
> straws here, in case we can parallelize the reviewing and merging
> process.

My preference is for a unified interface that caters to both
software compression as well as parallel hardware compression.

The reason is that there is clear advantage in passing a large
batch of pages to the Crypto API even for software compression,
the least we could do is to pack the compressed result together
and avoid the unnecessary copying of the compressed output that
is currently done in zswap.

However, since you guys are both happy with this patch-set,
I'm not going stand in the way.

But I do want some changes made to the proposed Crypto API interface
so that it can be reused for IPComp.

In particular, instead of passing an opaque pointer (kernel_data)
to magically turn on batching, please add a new helper that enables
batching.

I don't think we need any extra fields in struct acomp_req apart
from a new field called unit_size.  This would be 4096 for zswap,
it could be the MTU for IPsec.

So add something like this and document that it must be called
after acmop_request_set_callback (which should set unit_size to 0):

static inline void acomp_request_set_unit_size(struct acomp_req *req,
					       unsigned int du)
{
	req->unit = du;
}

static inline void acomp_request_set_callback(struct acomp_req *req, ...)
{
	...
+	req->unit = 0;
}

For the source, nothing needs to be done because the folio could
be passed in as is.

For the destination, construct an SG list for them and pass that in.
The rule should be that the SG list must contain a sufficient number
of pages for the compression output based on the given unit size.

For the output lengths, just set the lengths in the destination
SG list after compression.  If a page is incompressible (including
an error), just set the length to a negative value (-ENOSPC could
be used for incompressible input, as we already do).  Even though
struct scatterlist->length is unsigned, there should be no issue
with storing a negative value there.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt