Re: [PATCH] zram: Avoid duplicate slots in batched writeback

["David Hildenbrand (Arm)" <david@kernel.org>]

On 11/13/26 08:26, Andrew Morton wrote:
> On Tue, 10 Nov 2026 15:40:13 +0900 Sergey Senozhatsky <senozhatsky@chromium.org> wrote:
> 
>> On (26/11/10 14:18), raoxu wrote:
>>> The writeback interface accepts multiple page_index and page_indexes
>>> parameters in one operation. Their ranges can overlap, but
>>> scan_slots_for_writeback() only excludes slots that are already being
>>> written back or marked as same-filled.
>>>
>>> A slot selected by an earlier range is placed on the post-processing list
>>> and marked with ZRAM_PP_SLOT. Without checking that flag, an overlapping
>>> range can enqueue the same slot again and submit it for writeback more
>>> than once.
>>>
>>> Skip slots already marked ZRAM_PP_SLOT while holding the slot lock. This
>>> keeps each slot in a writeback scan session represented by at most one
>>> post-processing entry and leaves the existing release and reuse paths
>>> unchanged.
>>>
>>> Signed-off-by: Xu Rao <raoxu@uniontech.com>
>>
>> LGTM.
>> Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
>>
>> Jens, do you want to pick it up and route via block tree or should
>> we route via "more traditional" tree (Andrew's tree)?
> 
> I grabbed it.
> 
> I did recently attempt to pull zram out of the mm project, by moving it
> from mm.git's mm-unstable branch and into mm.git's mm-nonmm-unstable
> branch.  Because "why does the mm project contain a block device
> driver".
> 
> I undid that change after about a week - it didn't work out because
> zram is joined at the hip with mm/zsmalloc.c.  zsmalloc is also used by
> mm/zswap.c.

Are there cleaner ways of isolating both things?

Like, many drivers use kmalloc() etc, and they are not part of core-mm :)

-- 
Cheers,

David