linux-kernel - Re: [PATCH 2/3] zram: rename internal slot API

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: <20260114123658.1231407-1-clm@meta.com>
Date: Wed, 14 Jan 2026 04:36:54 -0800
From: Chris Mason <clm@...a.com>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
CC: Chris Mason <clm@...a.com>, Andrew Morton <akpm@...ux-foundation.org>,
        Minchan Kim <minchan@...nel.org>, Brian Geffon <bgeffon@...gle.com>,
        "David
 Stevens" <stevensd@...gle.com>, <linux-kernel@...r.kernel.org>,
        <linux-mm@...ck.org>, <linux-block@...r.kernel.org>
Subject: Re: [PATCH 2/3] zram: rename internal slot API

On Mon, 15 Dec 2025 14:47:12 +0900 Sergey Senozhatsky <senozhatsky@...omium.org> wrote:

> We have a somewhat confusing internal API naming.  E.g.
> the following code:
> 
> 	zram_slot_lock()
> 	if (zram_allocated())
> 		zram_set_flag()
> 	zram_slot_unlock()
> 
> may look like it does something on zram device level, but in
> fact it tests and sets slot entry flags, not the device ones.
> 
> Rename API to explicitly distinguish functions that operate on
> the slot level from functions that operate on the zram device
> level.
> 
> While at it, fixup some coding styles.

Hi everyone,

I ran mm-new through the AI patch review prompts and this one was flagged.
It uses a lot of words here to suggest a copy/paste error, but it does look
right to me:

> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 65f99ff3e2e54..f00f3d22d5e32 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c

[ ... ]

> +static void mark_slot_accessed(struct zram *zram, u32 index)
> +{
> +	clear_slot_flag(zram, index, ZRAM_IDLE);
> +	clear_slot_flag(zram, index, ZRAM_PP_SLOT);
> +#ifdef CONFIG_ZRAM_TRACK_ENTRY_ACTIME
> +	zram->table[index].attr.ac_time = ktime_get_boottime();
                                           ^^^^^^^^^^^^^^^^^^^^

The previous commit (472f3f208d78e "zram: use u32 for entry ac_time
tracking") changed this from ktime_get_boottime() to
(u32)ktime_get_boottime_seconds() because ac_time was changed from
ktime_t to u32.

This patch appears to revert that change, storing the result of
ktime_get_boottime() (which returns a 64-bit nanosecond value) into
the u32 ac_time field. This truncates to the lower 32 bits, which
wraps every ~4.29 seconds.

The result is that mark_idle() will compare ktime_after(cutoff, ac_time)
using a truncated nanosecond value, causing pages to be incorrectly
marked as IDLE almost immediately after being accessed.

Was this change intentional, or was it accidentally reverted during
the rename refactoring?

> +#endif
> +}

[ ... ]

> -static void zram_accessed(struct zram *zram, u32 index)
> -{
> -	zram_clear_flag(zram, index, ZRAM_IDLE);
> -	zram_clear_flag(zram, index, ZRAM_PP_SLOT);
> -#ifdef CONFIG_ZRAM_TRACK_ENTRY_ACTIME
> -	zram->table[index].attr.ac_time = (u32)ktime_get_boottime_seconds();
> -#endif
> -}

This is the original code that was correctly using
ktime_get_boottime_seconds() with the u32 cast. The new
mark_slot_accessed() function above should preserve this behavior.