public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrey Skvortsov <andrej.skvortzov@gmail.com>
To: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: Venkat Rao Bagalkote <venkat88@linux.vnet.ibm.com>,
	Minchan Kim <minchan@kernel.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Jens Axboe <axboe@kernel.dk>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v3] zram: don't free statically defined names
Date: Tue, 24 Sep 2024 01:41:48 +0300	[thread overview]
Message-ID: <ZvHurCYlCoi1ZTCX@skv.local> (raw)
In-Reply-To: <c8a4e62e-6c24-4b06-ac86-64cc4697bc2f@wanadoo.fr>

On 24-09-23 19:40, Christophe JAILLET wrote:
> Le 23/09/2024 à 18:48, Andrey Skvortsov a écrit :
> > When CONFIG_ZRAM_MULTI_COMP isn't set ZRAM_SECONDARY_COMP can hold
> > default_compressor, because it's the same offset as ZRAM_PRIMARY_COMP,
> > so we need to make sure that we don't attempt to kfree() the
> > statically defined compressor name.
> > 
> > This is detected by KASAN.
> > 
> > ==================================================================
> >    Call trace:
> >     kfree+0x60/0x3a0
> >     zram_destroy_comps+0x98/0x198 [zram]
> >     zram_reset_device+0x22c/0x4a8 [zram]
> >     reset_store+0x1bc/0x2d8 [zram]
> >     dev_attr_store+0x44/0x80
> >     sysfs_kf_write+0xfc/0x188
> >     kernfs_fop_write_iter+0x28c/0x428
> >     vfs_write+0x4dc/0x9b8
> >     ksys_write+0x100/0x1f8
> >     __arm64_sys_write+0x74/0xb8
> >     invoke_syscall+0xd8/0x260
> >     el0_svc_common.constprop.0+0xb4/0x240
> >     do_el0_svc+0x48/0x68
> >     el0_svc+0x40/0xc8
> >     el0t_64_sync_handler+0x120/0x130
> >     el0t_64_sync+0x190/0x198
> > ==================================================================
> > 
> > Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
> > Fixes: 684826f8271a ("zram: free secondary algorithms names")
> > Cc: <stable@vger.kernel.org>
> > ---
> > 
> > Changes in v2:
> >   - removed comment from source code about freeing statically defined compression
> >   - removed part of KASAN report from commit description
> >   - added information about CONFIG_ZRAM_MULTI_COMP into commit description
> > 
> > Changes in v3:
> >   - modified commit description based on Sergey's comment
> >   - changed start for-loop to ZRAM_PRIMARY_COMP
> > 
> > 
> >   drivers/block/zram/zram_drv.c | 6 ++++--
> >   1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index c3d245617083d..ad9c9bc3ccfc5 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ 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?

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

-- 
Best regards,
Andrey Skvortsov

  reply	other threads:[~2024-09-23 22:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-23 16:48 [PATCH v3] zram: don't free statically defined names Andrey Skvortsov
2024-09-23 17:40 ` Christophe JAILLET
2024-09-23 22:41   ` Andrey Skvortsov [this message]
2024-09-24  5:10     ` Sergey Senozhatsky
2024-09-24  5:21     ` Christophe JAILLET
2024-09-24  5:41       ` Sergey Senozhatsky
2024-09-24  5:49       ` Sergey Senozhatsky
2024-09-24  5:58         ` Sergey Senozhatsky
2024-09-24  6:50         ` Sergey Senozhatsky
2024-09-24  1:46   ` Sergey Senozhatsky
2024-09-24  1:42 ` Sergey Senozhatsky
2024-09-24  5:17   ` Sergey Senozhatsky
2024-09-24  8:15   ` Venkat Rao Bagalkote
2024-09-24 15:56     ` Chris Li
2024-09-24 18:29       ` Chris Li
2024-09-25  0:37         ` Sergey Senozhatsky
2024-09-25  4:04           ` Chris Li
2024-09-27 22:59             ` Chris Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZvHurCYlCoi1ZTCX@skv.local \
    --to=andrej.skvortzov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minchan@kernel.org \
    --cc=senozhatsky@chromium.org \
    --cc=stable@vger.kernel.org \
    --cc=venkat88@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox