linux-kernel - Re: [PATCHv1 0/6] zsmalloc: preemptible object mapping

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: <Z5pPDV3Ub6EeWCxD@google.com>
Date: Wed, 29 Jan 2025 15:53:49 +0000
From: Yosry Ahmed <yosry.ahmed@...ux.dev>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Minchan Kim <minchan@...nel.org>,
	Johannes Weiner <hannes@...xchg.org>, Nhat Pham <nphamcs@...il.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv1 0/6] zsmalloc: preemptible object mapping

On Wed, Jan 29, 2025 at 03:43:46PM +0900, Sergey Senozhatsky wrote:
> This is Part II of the series [1] that makes zram read() and write()
> preemptible.  This part focuses only zsmalloc because zsmalloc imposes
> atomicity restrictions on its users.  One notable example is object
> mapping API, which returns with:
> a) local CPU lock held
> b) zspage rwlock held
> 
> First, zsmalloc is converted to use sleepable RW-"lock" (it's atomic_t
> in fact) for zspage migration protection.  Second, a new handle mapping
> is introduced which doesn't use per-CPU buffers (and hence no local CPU
> lock), does fewer memcpy() calls, but requires users to provide a
> pointer to temp buffer for object copy-in (when needed).  Third, zram is
> converted to the new zsmalloc mapping API and thus zram read() becomes
> preemptible.
> 
> [1] https://lore.kernel.org/linux-mm/20250127072932.1289973-1-senozhatsky@chromium.org
> 
> RFC -> v1:
> - Only zspage->lock (leaf-lock for zs_map_object()) is converted
>   to a preemptible lock.  The rest of the zspool locks remain the
>   same (Yosry hated with passion the fact that in RFC series all
>   zspool looks would become preemptible).

Hated is a big word here, I was merely concerned about how the locking
changes would affect performance :P

> - New zs object mapping API (Yosry hated RFC API with passion).
>   We know have obj_read_begin()/obj_read_end() and obj_write().
> - obj_write() saves extra memcpy() calls for objects that span two
>   physical pages.
> - Dropped zram deferred slot-free-notification handling (I hated
>   it with passion)
> 
> Sergey Senozhatsky (6):
>   zsmalloc: factor out pool locking helpers
>   zsmalloc: factor out size-class locking helpers
>   zsmalloc: make zspage lock preemptible
>   zsmalloc: introduce new object mapping API
>   zram: switch to new zsmalloc object mapping API
>   zram: add might_sleep to zcomp API
> 
>  drivers/block/zram/zcomp.c    |   6 +-
>  drivers/block/zram/zcomp.h    |   2 +
>  drivers/block/zram/zram_drv.c |  28 +--
>  include/linux/zsmalloc.h      |   8 +
>  mm/zsmalloc.c                 | 372 ++++++++++++++++++++++++++--------
>  5 files changed, 311 insertions(+), 105 deletions(-)
> 
> -- 
> 2.48.1.262.g85cc9f2d1e-goog
>