linux-kernel - Re: [PATCH] zram: do not skip the first bucket

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: <20241001145739.8afe344d456d90fb6e8d96d6@linux-foundation.org>
Date: Tue, 1 Oct 2024 14:57:39 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: linux-kernel@...r.kernel.org, Dan Carpenter <dan.carpenter@...aro.org>
Subject: Re: [PATCH] zram: do not skip the first bucket

On Tue,  1 Oct 2024 17:55:56 +0900 Sergey Senozhatsky <senozhatsky@...omium.org> wrote:

> A small fixup.
> 
> ...
>
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -264,7 +264,7 @@ static struct zram_pp_slot *select_pp_slot(struct zram_pp_ctl *ctl)
>  	s32 idx = NUM_PP_BUCKETS - 1;
>  
>  	/* The higher the bucket id the more optimal slot post-processing is */
> -	while (idx > 0) {
> +	while (idx >= 0) {
>  		pps = list_first_entry_or_null(&ctl->pp_buckets[idx],
>  					       struct zram_pp_slot,
>  					       entry);

I hate to be a kernel bureaucrat, but there's a lot missing from this
changelog!

a) What are the user-visible runtime effects?

b) What is the Fixes:

c) Is a cc:stable needed?  If so, a) is super-relevant.

oh, it's a fix against the mm-unstable patch "zram: rework recompress
target selection strategy".  That's new information!  Please disregard
the above.

d) what was wrong with the original code?  And still a).

> Reported-by: Dan Carpenter <dan.carpenter@...aro.org>

e) what did Dan report ("Closes:")?

Sorry, but this is all stuff which you easily had available but which I
had to figure out.  And which I now present to other readers so they
needn't figure it out.  That would be inefficient!

Ho hum, anyway, thanks, applied as an effectively unchangelogged fix
against mm-unstable's "zram: rework recompress target selection
strategy".