From: Geliang Tang <geliangtang@gmail.com>
To: Coly Li <colyli@suse.de>, Kent Overstreet <kent.overstreet@gmail.com>
Cc: linux-bcache@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] bcache: use kmemdup_nul for CACHED_LABEL buffer
Date: Tue, 26 Feb 2019 18:01:02 +0800 [thread overview]
Message-ID: <20190226100102.GA10363@OptiPlex> (raw)
In-Reply-To: <04ebd070-3c9c-0cd4-f2d8-d7b078ea2582@suse.de>
On Wed, Feb 06, 2019 at 04:37:36PM +0800, Coly Li wrote:
> On 2019/1/30 5:29 下午, Geliang Tang wrote:
> > This patch uses kmemdup_nul to create a NUL-terminated string from
> > dc->sb.label. This is better than open coding it.
> >
> > With this, we can move env[2] initialization into env[] array to make
> > code more elegant.
> >
> > Signed-off-by: Geliang Tang <geliangtang@gmail.com>
>
> Hi Geliang,
>
> In general I am OK with your idea. But I feel there might be some
> regression with your change. I comment your patch in line, correct me if
> I am wrong.
>
>
> > ---
> > drivers/md/bcache/super.c | 10 ++++------
> > 1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
> > index 4dee119c3664..84ab241c8516 100644
> > --- a/drivers/md/bcache/super.c
> > +++ b/drivers/md/bcache/super.c
> > @@ -906,21 +906,18 @@ static int cached_dev_status_update(void *arg)
> > void bch_cached_dev_run(struct cached_dev *dc)
> > {
> > struct bcache_device *d = &dc->disk;
> > - char buf[SB_LABEL_SIZE + 1];
> > + char *buf = kmemdup_nul(dc->sb.label, SB_LABEL_SIZE, GFP_KERNEL);
>
> If kdumdup_null() is failed, buf will be NULL.
>
> > char *env[] = {
> > "DRIVER=bcache",
> > kasprintf(GFP_KERNEL, "CACHED_UUID=%pU", dc->sb.uuid),
> > - NULL,
> > + kasprintf(GFP_KERNEL, "CACHED_LABEL=%s", buf ? : ""),
>
> If buf is NULL, env[2] here is pointed to "" which is allocated in
> read-only data segment, and not a dynamic memory.
Hi Coly,
Sorry for my late reply.
If buf is NULL, env[2] is kasprintf(GFP_KERNEL, "CACHED_LABEL=%s", "");
In this case, env[2] is also a dynamic memory, a string like this, "CACHED_LABEL=".
So we can use kfree() to free it. There is no problem.
And here is a test case:
$ cat test.c
#include <linux/init.h>
#include <linux/module.h>
#include <linux/slab.h>
static int __init test_init(void)
{
char *env = kasprintf(GFP_KERNEL, "CACHED_LABEL=%s", "");
pr_info("env = [%s]\n", env);
kfree(env);
return 0;
}
static void __exit test_exit(void)
{
}
module_init(test_init);
module_exit(test_exit);
MODULE_LICENSE("GPL");
$ sudo insmod test.ko
$ dmesg
[ 3026.072298] env = [CACHED_LABEL=]
$ sudo rmmod test
Thanks.
-Geliang
>
> > NULL,
> > };
> >
> > - memcpy(buf, dc->sb.label, SB_LABEL_SIZE);
> > - buf[SB_LABEL_SIZE] = '\0';
> > - env[2] = kasprintf(GFP_KERNEL, "CACHED_LABEL=%s", buf);
> > -
> > if (atomic_xchg(&dc->running, 1)) {
> > kfree(env[1]);
> > kfree(env[2]);
>
> Then kfree() here will try to release a read-only memory segment. I
> guess this is problematic.
>
> > + kfree(buf);
> > return;
> > }
> >
> > @@ -944,6 +941,7 @@ void bch_cached_dev_run(struct cached_dev *dc)
> > kobject_uevent_env(&disk_to_dev(d->disk)->kobj, KOBJ_CHANGE, env);
> > kfree(env[1]);
> > kfree(env[2]);
>
> Same problem might happen here for env[2].
>
> > + kfree(buf);
> >
> > if (sysfs_create_link(&d->kobj, &disk_to_dev(d->disk)->kobj, "dev") ||
> > sysfs_create_link(&disk_to_dev(d->disk)->kobj, &d->kobj, "bcache"))
> >
>
>
> --
>
> Coly Li
next prev parent reply other threads:[~2019-02-26 10:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-30 9:29 [PATCH] bcache: use kmemdup_nul for CACHED_LABEL buffer Geliang Tang
2019-02-06 8:37 ` Coly Li
2019-02-26 10:01 ` Geliang Tang [this message]
2019-02-26 11:03 ` Coly 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=20190226100102.GA10363@OptiPlex \
--to=geliangtang@gmail.com \
--cc=colyli@suse.de \
--cc=kent.overstreet@gmail.com \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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