linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Jagdish Gediya <jvgediya@linux.ibm.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	rafael@kernel.org, akpm@linux-foundation.org,
	keescook@chromium.org, andriy.shevchenko@linux.intel.com,
	geert@linux-m68k.org, linux@roeck-us.net, adobriyan@gmail.com
Subject: Re: [PATCH] kobject: Refactor kobject_set_name_vargs()
Date: Fri, 6 May 2022 16:02:28 +0200	[thread overview]
Message-ID: <YnUqdBuxy7MofDoR@kroah.com> (raw)
In-Reply-To: <20220506133309.36794-1-jvgediya@linux.ibm.com>

On Fri, May 06, 2022 at 07:03:09PM +0530, Jagdish Gediya wrote:
> 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)
>  {
> -	const char *s;
> -
> -	if (kobj->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;
> -		strreplace(t, '/', '!');
> -		s = t;
> -	}
> -	kfree_const(kobj->name);
> -	kobj->name = s;
> -
> -	return 0;
> +	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)

Why is this a mm/ thing and not a lib/ thing?

And who else will be needing to use this?  Why the churn for no
actual users?

> +{
> +	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;
> +		strreplace(t, '/', '!');
> +		s = t;
> +	}
> +	kfree_const(*name);
> +	*name = s;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(set_name_vargs);

No need to export this as there are no users in modules.

And if there was, shouldn't it be EXPORT_SYMBOL_GPL() as that's what the
kobject functions are exported as (most of them at least.)

But again, why is this needed at all?

thanks,

greg k-h


  reply	other threads:[~2022-05-06 14:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-06 13:33 Jagdish Gediya
2022-05-06 14:02 ` Greg KH [this message]
2022-05-06 14:29   ` Jagdish Gediya
2022-05-06 14:45     ` Greg KH
2022-05-06 14:46 ` David Laight
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=YnUqdBuxy7MofDoR@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=geert@linux-m68k.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