[PATCH 0/2] zram: writeback fixes

[PATCH 0/2] zram: writeback fixes

[Sergey Senozhatsky]

Brian reported several issues with zram's writeback implementation.
This small series addresses those issues.

Sergey Senozhatsky (2):
  zram: do not leak blk idx at the end of writeback
  zram: clear trailing bytes of compressed writeback pages

 drivers/block/zram/zram_drv.c | 5 +++++
 1 file changed, 5 insertions(+)

-- 
2.54.0.746.g67dd491aae-goog

[PATCH 1/2] zram: do not leak blk idx at the end of writeback

[Sergey Senozhatsky]

In certain cases zram_writeback_slots() loop can terminate with
blk_idx being valid (in particular when we race with modification
of last slot) but zram_writeback_slots() forgets to release the
reserved block id, which leads to this block becoming unavailable
for future writeback.  Release valid blk_idx before returning from
zram_writeback_slots().

Suggested-by: Brian Geffon <bgeffon@google.com>
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
---
 drivers/block/zram/zram_drv.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 07111455eecf..602abfe23797 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1127,6 +1127,9 @@ static int zram_writeback_slots(struct zram *zram,
 	if (req)
 		release_wb_req(req);
 
+	if (blk_idx != INVALID_BDEV_BLOCK)
+		zram_release_bdev_block(zram, blk_idx);
+
 	while (atomic_read(&wb_ctl->num_inflight) > 0) {
 		wait_event(wb_ctl->done_wait, !list_empty(&wb_ctl->done_reqs));
 		err = zram_complete_done_reqs(zram, wb_ctl);
-- 
2.54.0.746.g67dd491aae-goog

[PATCH 2/2] zram: clear trailing bytes of compressed writeback pages

[Sergey Senozhatsky]

When compressed writeback is available writtenback pages
contain garbage PAGE_SIZE - obj_size trailing bytes. Zero
out those trailing bytes before writeback to a backing
device.

Suggested-by: Brian Geffon <bgeffon@google.com>
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
---
 drivers/block/zram/zram_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 602abfe23797..7917fc7a2a29 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -2134,6 +2134,8 @@ static int read_from_zspool_raw(struct zram *zram, struct page *page, u32 index)
 	zs_obj_read_end(zram->mem_pool, handle, size, src);
 	zcomp_stream_put(zstrm);
 
+	memzero_page(page, size, PAGE_SIZE - size);
+
 	return 0;
 }
 #endif
-- 
2.54.0.746.g67dd491aae-goog

Re: [PATCH 0/2] zram: writeback fixes

[Andrew Morton]

On Mon, 25 May 2026 13:46:00 +0900 Sergey Senozhatsky <senozhatsky@chromium.org> wrote:

> Brian reported several issues with zram's writeback implementation.
> This small series addresses those issues.

I hate to go all bureaucratic, but there's quite a lot missing here,
and it's rather important, to some.  It's all about taking care of
people who are using kernels prior to 7.2 (or 7.1).

- Link: to Brian's reports?

- Description of user-visible runtime effects of the bugs?

- Fixes: targets?

- Decision on whether we should backport the fixes into earlier kernels?

Anyway, I'll queue these in mm-new, but please give some thought to the
above?

Also, AI review didn't find anything to complain about with these
changes, but it might have found a pre-existing issue:

	https://sashiko.dev/#/patchset/20260525044639.1888561-1-senozhatsky@chromium.org

Thanks.

Re: [PATCH 0/2] zram: writeback fixes

[Sergey Senozhatsky]

On (26/05/25 14:31), Andrew Morton wrote:
> > Brian reported several issues with zram's writeback implementation.
> > This small series addresses those issues.
> 
> I hate to go all bureaucratic, but there's quite a lot missing here,
> and it's rather important, to some.  It's all about taking care of
> people who are using kernels prior to 7.2 (or 7.1).

Sorry, Andrew, it was just me being lazy.

> - Link: to Brian's reports?
> 
> - Description of user-visible runtime effects of the bugs?
> 
> - Fixes: targets?
> 
> - Decision on whether we should backport the fixes into earlier kernels?

I updated commit messages and sent out v2.  The reports are private,
so on public links.  Both issues are low risk.

[..]

> Also, AI review didn't find anything to complain about with these
> changes, but it might have found a pre-existing issue:
> 
> 	https://sashiko.dev/#/patchset/20260525044639.1888561-1-senozhatsky@chromium.org

Correct, a pre-existing issue (first appeared in v6.19), we fix it in this
series.  The theoretical data leak issue first appeared in v7.0.