[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240924014632.GI38742@google.com>
Date: Tue, 24 Sep 2024 10:46:32 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc: Andrey Skvortsov <andrej.skvortzov@...il.com>,
Venkat Rao Bagalkote <venkat88@...ux.vnet.ibm.com>,
Minchan Kim <minchan@...nel.org>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Jens Axboe <axboe@...nel.dk>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH v3] zram: don't free statically defined names
On (24/09/23 19:40), Christophe JAILLET wrote:
[..]
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -2115,8 +2115,10 @@ static void zram_destroy_comps(struct zram *zram)
> > zram->num_active_comps--;
> > }
> > - for (prio = ZRAM_SECONDARY_COMP; prio < ZRAM_MAX_COMPS; prio++) {
> > - kfree(zram->comp_algs[prio]);
> > + for (prio = ZRAM_PRIMARY_COMP; prio < ZRAM_MAX_COMPS; prio++) {
> > + /* Do not free statically defined compression algorithms */
> > + if (zram->comp_algs[prio] != default_compressor)
> > + kfree(zram->comp_algs[prio]);
>
> Hi,
>
> maybe kfree_const() to be more future proof and less verbose?
I didn't know about kfree_const(). If we change ->comp_algs release
to kfree_const(), then I'd probably prefer it to be a separate patch
that changes both zram_destroy_comps() and comp_algorithm_set(). The
current patch works for the way it is, given that it fixes a nasty
problem.
Powered by blists - more mailing lists