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@xxxxxxxxxxxx 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). - 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
