[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240924054151.GL38742@google.com>
Date: Tue, 24 Sep 2024 14:41:51 +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/24 07:21), Christophe JAILLET wrote:
> > > Hi,
> > >
> > > maybe kfree_const() to be more future proof and less verbose?
> >
> > kfree_const() will not work if zram is built as a module. It works
> > only for .rodata for kernel image. [1]
> >
> > 1. https://elixir.bootlin.com/linux/v6.11/source/include/asm-generic/sections.h#L177
> >
>
> If so, then it is likely that it is not correctly used elsewhere.
Oh, apparently there are drivers that use it...
So I suspect it works when you do
kstrdup_const()
kfree_const()
// I only looked at drivers/firmware/arm_scmi/bus.c
kstrdup_const() can't tell module's .rodata so it does plain
kstrdup() and then kfree_const() (for the same reason) does
plain kfree().
But calling kfree_const() on something that has not been
kstrdup_const() is unlikely to work as intended for modules.
So I guess kfree_const() works only when paired with kstrdup_const().
Powered by blists - more mailing lists