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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.