Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4669177iob; Sun, 8 May 2022 21:19:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy1beNTwRf35CyhMIv/3fUzRoVzrO3vE2I9nFN8q997hJyopp0xmtwGQprHIXq3U8W4u1q+ X-Received: by 2002:a17:902:d490:b0:15e:b443:6852 with SMTP id c16-20020a170902d49000b0015eb4436852mr14436383plg.111.1652069950064; Sun, 08 May 2022 21:19:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652069950; cv=none; d=google.com; s=arc-20160816; b=baJfY4vn8dJs+1gbo1mfXccLe43LvHvuv8BNxkWpzhjEYhnVjATHVmq8+hbHsbMGGv lK5jKgJWe52i0iBuU3UVomyDE2lUrlakFq7JkAXGcAe4AdEspLPUaxY3VsSLPUt0H5X0 fwy/YzEGFzGjzdHo5dJQckkztkBGDzTaGA4cXxkF1a34145dvPYHWCd5M5SfonLKOiSz KEji1HR0cBkIEfyubV9ByOPGubNsB2HmhaZhJ8izioEjFvs/xZKN+3qPsiqRvB4uaS+6 iercqj7R+R+qndTNUwmAWtmYLMMjNhpKur/b1joqNDpdB2QkmQt54FA5HvO5s7gHDDEP TBfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=eN4oyTuVM5OnhDDwWoY/Q3Pcq2IuU+XbPEINLtwb2fU=; b=V4GupA8fs5Czb1wWFdl6Oj2gVo7Ivvv8zSdFXAnvpMCycNU7ZZpuFGnVTgaxU3lAk0 PSCa3yK4sfV9sBY2RFGSZ5tM8ozZ4crztJSfRzAA/LEN2X94/ymqaG0LMBgFHKmbQ3rK o2jJSeoDA6WJM9r1h1sL5AMahTBQzRrKFHv2tYMfxeiGxF2mRboqF5WhDyws9XJFPxhV YQnY2twMd0hYHdqtNDNMrZ4RFjcF+wddJLUanCJV7GN7VDO5rixPbwynXmjukv/N6HBd XF72FCHPOrH7FGSwwUZTRcwCUlH9tIPX2T/IfSJtwQcxlZWHEYHm81N10SnQV9QBwq02 NKLA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=hgHW1zQu; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id l63-20020a639142000000b003aa193b6cfbsi12775188pge.174.2022.05.08.21.19.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 May 2022 21:19:10 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=hgHW1zQu; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 81CB5269; Sun, 8 May 2022 21:15:33 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1442399AbiEFOtq (ORCPT + 99 others); Fri, 6 May 2022 10:49:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237385AbiEFOto (ORCPT ); Fri, 6 May 2022 10:49:44 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D7D706AA4F for ; Fri, 6 May 2022 07:46:00 -0700 (PDT) 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 dfw.source.kernel.org (Postfix) with ESMTPS id 72B7162183 for ; Fri, 6 May 2022 14:46:00 +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-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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