public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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