From: David Laight <David.Laight@ACULAB.COM>
To: 'Jagdish Gediya' <jvgediya@linux.ibm.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"rafael@kernel.org" <rafael@kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Cc: "keescook@chromium.org" <keescook@chromium.org>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>,
"geert@linux-m68k.org" <geert@linux-m68k.org>,
"linux@roeck-us.net" <linux@roeck-us.net>,
"adobriyan@gmail.com" <adobriyan@gmail.com>
Subject: RE: [PATCH] kobject: Refactor kobject_set_name_vargs()
Date: Fri, 6 May 2022 14:46:47 +0000 [thread overview]
Message-ID: <5902e26ef400451b966be2dd0fbd1575@AcuMS.aculab.com> (raw)
In-Reply-To: <20220506133309.36794-1-jvgediya@linux.ibm.com>
From: Jagdish Gediya
> Sent: 06 May 2022 14:33
>
> Setting name as per the format is not only useful for kobjects.
> It can also be used to set name for other things for e.g. setting
> the name of the struct attribute when multiple same kind of attributes
> need to be created with some identifier in name, instead of managing
> memory for names at such places case by case, it would be good if
> something like current kobject_set_name_vargs() can be utilized.
>
> Refactor kobject_set_name_vargs(), Create a new generic function
> set_name_vargs() which can be used for kobjects as well as at
> other places.
>
> This patch doesn't introduce any functionality change.
>
> Signed-off-by: Jagdish Gediya <jvgediya@linux.ibm.com>
> ---
> include/linux/string.h | 1 +
> lib/kobject.c | 30 +-----------------------------
> mm/util.c | 40 ++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 42 insertions(+), 29 deletions(-)
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index b6572aeca2f5..f329962e5ae9 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -9,6 +9,7 @@
> #include <linux/stdarg.h>
> #include <uapi/linux/string.h>
>
> +int set_name_vargs(const char **name, const char *fmt, va_list vargs);
> extern char *strndup_user(const char __user *, long);
> extern void *memdup_user(const void __user *, size_t);
> extern void *vmemdup_user(const void __user *, size_t);
> diff --git a/lib/kobject.c b/lib/kobject.c
> index 5f0e71ab292c..870d05971e3a 100644
> --- a/lib/kobject.c
> +++ b/lib/kobject.c
> @@ -249,35 +249,7 @@ static int kobject_add_internal(struct kobject *kobj)
> int kobject_set_name_vargs(struct kobject *kobj, const char *fmt,
> va_list vargs)
> {
...
> + return set_name_vargs(&kobj->name, fmt, vargs);
> }
>
> /**
> diff --git a/mm/util.c b/mm/util.c
> index 54e5e761a9a9..808d29b17ea7 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -112,6 +112,46 @@ char *kstrndup(const char *s, size_t max, gfp_t gfp)
> }
> EXPORT_SYMBOL(kstrndup);
>
> +/**
> + * set_name_vargs() - Set the name as per format
> + * @name: pointer to point to the name as per format
> + * @fmt: format string used to build the name
> + * @vargs: vargs to format the string.
> + */
> +int set_name_vargs(const char **name, const char *fmt, va_list vargs)
> +{
> + const char *s;
> +
> + if (*name && !fmt)
> + return 0;
> +
> + s = kvasprintf_const(GFP_KERNEL, fmt, vargs);
> + if (!s)
> + return -ENOMEM;
> +
> + /*
> + * ewww... some of these buggers have '/' in the name ... If
> + * that's the case, we need to make sure we have an actual
> + * allocated copy to modify, since kvasprintf_const may have
> + * returned something from .rodata.
> + */
> + if (strchr(s, '/')) {
> + char *t;
> +
> + t = kstrdup(s, GFP_KERNEL);
> + kfree_const(s);
> + if (!t)
> + return -ENOMEM;
There is a kstrdup_const() that will DTRT here.
> + strreplace(t, '/', '!');
> + s = t;
> + }
> + kfree_const(*name);
> + *name = s;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(set_name_vargs);
Are you sure this can ever work from a module?
This all relies on:
static inline bool is_kernel_rodata(unsigned long addr)
{
return addr >= (unsigned long)__start_rodata &&
addr < (unsigned long)__end_rodata;
}
which isn't going to do anything sane given an "xxx" inside a module.
Indeed can kobject_set_name_vargs() end up with a constant string
inside a module?
Seems horribly fragile.
David
> +
> /**
> * kmemdup - duplicate region of memory
> *
> --
> 2.35.1
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2022-05-06 14:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-06 13:33 [PATCH] kobject: Refactor kobject_set_name_vargs() Jagdish Gediya
2022-05-06 14:02 ` Greg KH
2022-05-06 14:29 ` Jagdish Gediya
2022-05-06 14:45 ` Greg KH
2022-05-06 14:46 ` David Laight [this message]
2022-05-06 17:24 ` Jagdish Gediya
2022-05-07 10:01 ` David Laight
2022-05-06 19:56 ` kernel test robot
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=5902e26ef400451b966be2dd0fbd1575@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=jvgediya@linux.ibm.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@roeck-us.net \
--cc=rafael@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;
as well as URLs for NNTP newsgroup(s).