Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1101710ybl; Fri, 6 Dec 2019 11:16:15 -0800 (PST) X-Google-Smtp-Source: APXvYqxRCYrIFiEDQ7o5XwFPS8YVnl5LaiJ92qFu6aYYHyz2Lu+D4EqIFewFSLKw5f8KM/VUTFB8 X-Received: by 2002:a05:6808:3a9:: with SMTP id n9mr7983687oie.31.1575659775297; Fri, 06 Dec 2019 11:16:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575659775; cv=none; d=google.com; s=arc-20160816; b=gg9u8hDypsqKgPCSBJIUWvbeoPhajGoYw5HHGk0Rsorw9X/ipVHVjUAsIgQaxnCJs0 wWcIOyolq6HXRJSAfrYATxX0qdor6+/ApAbbZO1laltLuICrIBA192lXZLfUQXuI9D9j fLPOi5WCHTbhj/ydB7PRt0tSBz7BnWBbMJ/dl/vNkMGUSdBWYh1NldxoU82E2R9Q4CIr XhDu9WOVAZwnbiKKguS9SGF2Xf4cGaekVG6AjoVT1bGVOxabBM6JOOenxPL58DVlwHAq XuO9RYZJwaHpA855Vxbc1Qm1flVGbH7tNjGeiaZ38G+96w5P6mHWn7+bO6duHU3tzNlx U3sQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=5OG4gVQNgTqoxKYqEdf72o9H+A7nENvn5a5hg8Mjv2k=; b=IdUD2zJ7NR41pJsBTQ4Wjzg8LFf9Nas5eSeU/hqA4DAt4vlbyskiKa+1SuT7DItsRJ Dsn3mIN9Jajr2sO9+0KMEnoFzh56+cKvzZxIx3+/zaqhqiH8GGLWdzgYpNk3U7y2Smiw jLb+7voOi8aUXHBeOwtkWV8v/JPIzzwY+yogggdi5T6UQHGicOJfA84F5fj3DsbuPrVm 6rp9nzfmIA5c3RjuhkRsSuZMbSul0xot8+Ee4t5fxg4YgfNC5MXRYIJiQm010F3HtX4E cdXmbaObx5mHXnG3iGEPsKV0CYvD4qcStQ0PjoP5fhEzn5udFb6hWR+sbloq1ltrP/HP XJVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=1kJqvtEe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v141si7885581oif.161.2019.12.06.11.16.00; Fri, 06 Dec 2019 11:16:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=1kJqvtEe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726464AbfLFTOZ (ORCPT + 99 others); Fri, 6 Dec 2019 14:14:25 -0500 Received: from mail.kernel.org ([198.145.29.99]:47010 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726321AbfLFTOZ (ORCPT ); Fri, 6 Dec 2019 14:14:25 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4B65321835; Fri, 6 Dec 2019 19:14:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1575659663; bh=LPnXnjKbm0b4gtrlcehg2oiRCOVCNtSW0HjJxtovOtQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=1kJqvtEecr1K6h1tqyXRWHiTEmaVksOxPW/2vTlWvPJzQ7b0SUYP7gfqyC5qkz/Iu 6kegACy2K8Jz/ABZjfANuBWSi1JjqBBrcgv/k+qb1LhEbQW4MKdx9KPFBzZzbxfvIj 8b3jh3FVbJb3+gHUf1m9TLx0UeZNEQyivQAJf8yI= Date: Fri, 6 Dec 2019 20:14:20 +0100 From: Greg KH To: Sourabh Jain Cc: mpe@ellerman.id.au, mahesh@linux.vnet.ibm.com, hbathini@linux.ibm.com, linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, corbet@lwn.net, linux-doc@vger.kernel.org Subject: Re: [PATCH v4 2/6] sysfs: wrap __compat_only_sysfs_link_entry_to_kobj function to change the symlink name Message-ID: <20191206191420.GA192422@kroah.com> References: <20191206122434.29587-1-sourabhjain@linux.ibm.com> <20191206122434.29587-3-sourabhjain@linux.ibm.com> <20191206124642.GB1360047@kroah.com> <3aabdf19-ccbf-e99a-c560-2b110e8b536a@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3aabdf19-ccbf-e99a-c560-2b110e8b536a@linux.ibm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 06, 2019 at 11:57:53PM +0530, Sourabh Jain wrote: > > > On 12/6/19 6:16 PM, Greg KH wrote: > > On Fri, Dec 06, 2019 at 05:54:30PM +0530, Sourabh Jain wrote: > >> The __compat_only_sysfs_link_entry_to_kobj function creates a symlink to a > >> kobject but doesn't provide an option to change the symlink file name. > >> > >> This patch adds a wrapper function create_sysfs_symlink_entry_to_kobj that > >> extends the __compat_only_sysfs_link_entry_to_kobj functionality which > >> allows function caller to customize the symlink name. > >> > >> Signed-off-by: Sourabh Jain > >> --- > >> fs/sysfs/group.c | 28 +++++++++++++++++++++++++--- > >> include/linux/sysfs.h | 12 ++++++++++++ > >> 2 files changed, 37 insertions(+), 3 deletions(-) > >> > >> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c > >> index d41c21fef138..5eb38145b957 100644 > >> --- a/fs/sysfs/group.c > >> +++ b/fs/sysfs/group.c > >> @@ -424,6 +424,25 @@ EXPORT_SYMBOL_GPL(sysfs_remove_link_from_group); > >> int __compat_only_sysfs_link_entry_to_kobj(struct kobject *kobj, > >> struct kobject *target_kobj, > >> const char *target_name) > >> +{ > >> + return create_sysfs_symlink_entry_to_kobj(kobj, target_kobj, > >> + target_name, NULL); > >> +} > >> +EXPORT_SYMBOL_GPL(__compat_only_sysfs_link_entry_to_kobj); > >> + > >> +/** > >> + * create_sysfs_symlink_entry_to_kobj - add a symlink to a kobject pointing > >> + * to a group or an attribute > >> + * @kobj: The kobject containing the group. > >> + * @target_kobj: The target kobject. > >> + * @target_name: The name of the target group or attribute. > >> + * @symlink_name: The name of the symlink file (target_name will be > >> + * considered if symlink_name is NULL). > >> + */ > >> +int create_sysfs_symlink_entry_to_kobj(struct kobject *kobj, > >> + struct kobject *target_kobj, > >> + const char *target_name, > >> + const char *symlink_name) > >> { > >> struct kernfs_node *target; > >> struct kernfs_node *entry; > >> @@ -448,12 +467,15 @@ int __compat_only_sysfs_link_entry_to_kobj(struct kobject *kobj, > >> return -ENOENT; > >> } > >> > >> - link = kernfs_create_link(kobj->sd, target_name, entry); > >> + if (!symlink_name) > >> + symlink_name = target_name; > >> + > >> + link = kernfs_create_link(kobj->sd, symlink_name, entry); > >> if (IS_ERR(link) && PTR_ERR(link) == -EEXIST) > >> - sysfs_warn_dup(kobj->sd, target_name); > >> + sysfs_warn_dup(kobj->sd, symlink_name); > >> > >> kernfs_put(entry); > >> kernfs_put(target); > >> return PTR_ERR_OR_ZERO(link); > >> } > >> -EXPORT_SYMBOL_GPL(__compat_only_sysfs_link_entry_to_kobj); > >> +EXPORT_SYMBOL_GPL(create_sysfs_symlink_entry_to_kobj); > >> diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h > >> index 5420817ed317..123c6f10333a 100644 > >> --- a/include/linux/sysfs.h > >> +++ b/include/linux/sysfs.h > >> @@ -300,6 +300,10 @@ void sysfs_remove_link_from_group(struct kobject *kobj, const char *group_name, > >> int __compat_only_sysfs_link_entry_to_kobj(struct kobject *kobj, > >> struct kobject *target_kobj, > >> const char *target_name); > >> +int create_sysfs_symlink_entry_to_kobj(struct kobject *kobj, > >> + struct kobject *target_kobj, > >> + const char *target_name, > >> + const char *symlink_name); > > > > sysfs_create_symlink_entry_to_kobj()? > > > > I can't remember why we put __compat_only there, perhaps because we do > > not want people to really use this unless you really really have to? > > We don't have much option here. I tried replicating the sysfs files > in older patch series but creating symlink at old location is much > better approach. > > The __compat_only_sysfs_link_entry_to_kobj function is pretty generic, > unable to understand the reason behind restricting its usage. > > > > > So then keep compat_only here as well? > > Sure, I will rename the wrapper function. > > But how about changing the function signature instead of creating > a wrapper function? > > Considering the fact that there are only two places this function > has called. > > > > > What breaks if you remove those undocumented sysfs files? What > > userspace tool do you have that will even notice? > > The scripts used in kdump service need those sysfs files to control > the dump collection. So we can't just move the sysfs files to the > new location. If you can not change them, then just document them and live with it. Why do this extra work to create a symlink for something you will never use? greg k-h