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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <5n73klpww36wzux64rmfa6iialqkrgw2ft34vtarwkzdq65yct@txn2ylzkfmr3>
Date: Tue, 13 Jan 2026 11:36:47 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Yosry Ahmed <yosry.ahmed@...ux.dev>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>, 
	Herbert Xu <herbert@...dor.apana.org.au>, 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 (26/01/12 20:56), Yosry Ahmed wrote:
> > > Looks alright to me too.
> > > 
> > > > > +		size_t sizes[2];
> > > > > +
> > > > > +		/* this object spans two pages */
> > > > > +		sizes[0] = PAGE_SIZE - off;
> > > > > +		sizes[1] = mem_len - sizes[0];
> > > > > +
> > > > > +		sg_init_table(sg, 2);
> > > > > +		sg_set_page(sg, zpdesc_page(zpdesc), sizes[0], off);
> > > > > +
> > > > > +		zpdesc = get_next_zpdesc(zpdesc);
> > > > > +		sg = sg_next(sg);
> > > > 
> > > > Is this stateful? Will the SG list be returned pointing at the second
> > > > page now?
> > > 
> > > It makes no difference because we just called sg_init_table(sg, 2),
> > > so sg_next(sg) is equivalent to &sg[1].
> > 
> > I did it this way for (sort of) consistency: sg next follows zpdesc next.
> 
> Makes sense, I think I confused myself earlier. Do you plan to switch
> the existing interfaces to use SG lists for both zswap and zram? Or does
> zram still need the old interfaces?

That's a good question.  I don't know.  I was thinking of providing
SG-list based API for zswap first and keeping zram as is, for now.
zram doesn't use crypto API at the moment so supporting new interface
will come with extra work.