linux-kernel - Re: [RFC PATCH 2/2] zsmalloc: chain-length configuration should consider other metrics

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: <dou7g3n5fpynsab7hmxf4bgmqdewtdhkkiriwlghxzyduick7h@bsi3q2kivvbs>
Date: Tue, 6 Jan 2026 16:24:45 +0000
From: Yosry Ahmed <yosry.ahmed@...ux.dev>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, Nhat Pham <nphamcs@...il.com>, Minchan Kim <minchan@...nel.org>, 
	Johannes Weiner <hannes@...xchg.org>, Brian Geffon <bgeffon@...gle.com>, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org
Subject: Re: [RFC PATCH 2/2] zsmalloc: chain-length configuration should
 consider other metrics

On Tue, Jan 06, 2026 at 01:08:09PM +0800, Herbert Xu wrote:
> On Tue, Jan 06, 2026 at 01:22:45PM +0900, Sergey Senozhatsky wrote:
> > On (26/01/06 13:20), Sergey Senozhatsky wrote:
> > [..]
> > > > I am not sure tbh, adding Herbert here. I remember looking at the code
> > > > in scomp_acomp_comp_decomp() at some point, and I think it will take
> > > > care of non-contiguous SG-lists. Not sure if that's the correct place to
> > > > look tho.
> > > 
> > > Ah, so it does kmap under the hood.  I suppose that can work.
> > 
> > I'm hallucinating, sorry.  Yeah, let's hear from Herbert what's
> > the direction here.
> 
> I have not implemented the underlying SG support yet because
> there are no users in the kernel as of now.  But if this is
> useful for you then we can certainly do this, at least for
> LZO which is fairly simple.

Just to clarify, IIUC the SG support would mean that zram or zswap can
pass a non-contiguous SG-list to the crypto API, regardless of
compressor support. I assume that the crypto layer will either pass the
SG-list as-is to the compressor if it supports it, or copy it into
scratch space to be contiguous if needed.

So zswap, for example, will get an SG list from zsmalloc and pass it
directly to the crypto API for decompression. Then the effort to add
support to compressors can be done separately.

Did I get this right?

> 
> 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