linux-kernel - Re: [PATCH v4 0/2] rust: zpool: add abstraction for zpool drivers

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <c0b9d34e-1a21-4a97-b898-c33f7c8b49dd@suse.cz>
Date: Fri, 5 Sep 2025 08:58:00 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Vitaly Wool <vitaly.wool@...sulko.se>,
 Johannes Weiner <hannes@...xchg.org>
Cc: rust-for-linux <rust-for-linux@...r.kernel.org>,
 LKML <linux-kernel@...r.kernel.org>, Uladzislau Rezki <urezki@...il.com>,
 Danilo Krummrich <dakr@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 "Liam R . Howlett" <Liam.Howlett@...cle.com>, Miguel Ojeda
 <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
 Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
 Bjorn Roy Baron <bjorn3_gh@...tonmail.com>, Benno Lossin
 <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>,
 Trevor Gross <tmgross@...ch.edu>, Yosry Ahmed <yosry.ahmed@...ux.dev>,
 Nhat Pham <nphamcs@...il.com>, linux-mm@...ck.org
Subject: Re: [PATCH v4 0/2] rust: zpool: add abstraction for zpool drivers

On 8/26/25 16:56, Vitaly Wool wrote:
> 
> 
>> On Aug 26, 2025, at 2:44 PM, Johannes Weiner <hannes@...xchg.org> wrote:
>> 
>> On Sat, Aug 23, 2025 at 03:04:19PM +0200, Vitaly Wool wrote:
>>> Zpool is a common frontend for memory storage pool implementations.
>>> These pools are typically used to store compressed memory objects,
>>> e. g. for Zswap, the lightweight compressed cache for swap pages.
>>> 
>>> This patch provides the interface to use Zpool in Rust kernel code,
>>> thus enabling Rust implementations of Zpool allocators for Zswap.
>> 
>> The zpool indirection is on its way out.
>> 
>> When you submitted an alternate allocator backend recently, the
>> resounding feedback from the zswap maintainers was that improvements
>> should happen to zsmalloc incrementally. It is a lot of code and has a
>> lot of features that go beyond allocation strategy. We do not want to
>> fork it and fragment this space again with niche, incomplete backends.
>> 
>> It's frustrating that you not only ignored this, but then went ahead
>> and made other people invest their time and effort into this as well.
>> 
> 
> I don’t think we have a consensus on that.
> 
> And zblock is, after some additional improvements, just better than
> zsmalloc in all meaningful aspects, let alone the simplicity. It is fas
> easier to implement in Rust than zsmalloc, too. Besides, zram is a good
> candidate to be rewritten in Rust as well and after that is done, zblock

If your target is zram (not zswap) then I don't understand why insist on the
zpool layer, as zram refused to adopt it in the first place?

> will be even safer and faster. So while not being “incomplete", it’s
> zsmalloc that is becoming a niche backend moving forward, and I would
> argue that it could make more sense to eventually obsolete *it* rather
> than the zpool API.
> 
> ~Vitaly