From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4CF55C433EF for ; Fri, 6 May 2022 14:46:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF7FE6B0072; Fri, 6 May 2022 10:46:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA5A36B0073; Fri, 6 May 2022 10:46:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96DE96B0074; Fri, 6 May 2022 10:46:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0086.hostedemail.com [216.40.44.86]) by kanga.kvack.org (Postfix) with ESMTP id 8859C6B0072 for ; Fri, 6 May 2022 10:46:04 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 454A3A62E7 for ; Fri, 6 May 2022 14:46:04 +0000 (UTC) X-FDA: 79435593048.25.889C330 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf06.hostedemail.com (Postfix) with ESMTP id 30F19180049 for ; Fri, 6 May 2022 14:46:01 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 30600B835B5; Fri, 6 May 2022 14:46:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1C6E3C385A9; Fri, 6 May 2022 14:45:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1651848359; bh=dt3SW02BPv3YTpbIluUNorJpzYBDvB4r8puRjZ99wQc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hgHW1zQuSuKrrPIEYaP5KDri1u+7tR0pdT7nK33J7gLBc67/QiVwEMEc/dVM9sSAY luD9lKpdZGEkGmSjMaReO7OAmaF5oo5oAu6Eaj+NWtdzuGbMjV5hm3iIlcMqtFCz8W 2yQVy4stVmuyeoN2L414bYRADVZJVglHVPd2entA= Date: Fri, 6 May 2022 16:45:56 +0200 From: Greg KH To: Jagdish Gediya 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() Message-ID: References: <20220506133309.36794-1-jvgediya@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: w96tyop1rrnspwcfcdcw1m4mfeiejxk3 Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=hgHW1zQu; spf=pass (imf06.hostedemail.com: domain of gregkh@linuxfoundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 30F19180049 X-HE-Tag: 1651848361-608324 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, May 06, 2022 at 07:59:42PM +0530, Jagdish Gediya wrote: > On Fri, May 06, 2022 at 04:02:28PM +0200, Greg KH wrote: > > 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 > > > --- > > > 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 > > > #include > > > > > > +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? > > I think it can be moved to lib/, Will correct it in next version. > > > And who else will be needing to use this? Why the churn for no > > actual users? > > I am working on a sepatare series for memory tiers where this kind > of functionality is needed, Based on numa topology of the system, > We can build the memory tiers nodemasks based on numa distances, > such masks need to be viewed/stored from sysfs using interfaces > /sys/*/memory_tier0, /sys/*/memory_tier1 etc. there can be upto > MAX_TIERS of memory tiers in the system, so we can define struct > device_attribute array statically but their names need to be set > as per tier number where this function is useful. > > Also I think this requirement is generic although there are no > current users, It would be useful to not just restrict it to > kobjects. We don't make changes unless they are needed. This can be part of a patch series that uses the change, otherwise it's unneeded churn right now. thanks, greg k-h