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] [day] [month] [year] [list]

Message-ID: <20241002012938.GH11458@google.com>
Date: Wed, 2 Oct 2024 10:29:38 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
	linux-kernel@...r.kernel.org,
	Dan Carpenter <dan.carpenter@...aro.org>
Subject: Re: [PATCH] zram: do not skip the first bucket

On (24/10/01 14:57), Andrew Morton 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!

Oh, sorry.  I thought that would be just a fixup patch that gets
squashed with the patch it was applied against.

> a) What are the user-visible runtime effects?

There aren't too many.  Buckets are size classes that hold compressed
objects' indexes (zram slots) that are candidates for post-processing
(re-compression of writeback).  The bucket 0 was skipped before, which
is the bucket for compressed objects smaller than 64 bytes.  We rarely
have anything there, such level of compression (PAGE_SIZE -> 64 bytes)
is not common in general.  The lower the bucket index the less
interested we are in post-processing of the items there.  E.g.
recompression of a 64 bytes object with more efficient algorithm,
even if successful, probably will save us just a couple of bytes.

> b) What is the Fixes:

It doesn't fix any upstream commit, the code in question is in
mm-unstable.

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

No.  And a) is not 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.

Oh, yes, correct.  This series:
https://lore.kernel.org/linux-kernel/20240917021020.883356-1-senozhatsky@chromium.org

> 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:")?

It doesn't close any known/reported issue.  The Reported-by tag there
is to give Dan credit for spotting that "typo".

> 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!

My bad, sir.

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

Thank you.