Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp5075198ybc; Tue, 26 Nov 2019 21:00:33 -0800 (PST) X-Google-Smtp-Source: APXvYqz30pqszPSYq9AOKULOVb0q1HgTLIf+nMoJkyC8uIgo+2s24CnUUHqnjpT51aqpo2PZN/WR X-Received: by 2002:a17:906:6dcd:: with SMTP id j13mr1505970ejt.275.1574830833417; Tue, 26 Nov 2019 21:00:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574830833; cv=none; d=google.com; s=arc-20160816; b=kFAcwYOuF6ONR8VIAc35qXyY6vAhQ5W80SrIzlL3iGKTB0ZS69U9pKugVfAvzx+yuF RvXsgadUpfRnmMVVgIkEhIZDz+CzhZXjInGom+brKkrpBFUurtPE0huD/Dk92140Za8P 0kgCNLeWgt1bvwwcSK5y2rxrI0gn3KOIzoSA7JqOKIMkKYZyL5DxJG4u6MnRVvk/FS8T IZtO00VnmKFmiD5RmyOJ5C5EwilYgmEyTG90GosCZNCrYxQMx/jUh1JhjYferHMRJthC xledjfz8HnU7mHyRps3IvMZxR2VWedYgHwF30vrRpiBgCtFxPPwdkQoKIdTbW0l6cgN8 iEsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date:from :references:cc:to:subject; bh=xlgShkqsoeqb2O4x3EAJ5yOCn8zQdBoK0zHNYL6pZIc=; b=xgyYcJUbZwXqnyDBdej3gCrmACf/4wU4WF+qCO+e5dZpWjHgfqWJPe18UyMDAHiGIJ 8i6DPRPJKieab76BA8JTF5mYclq3dBMTOfmYdQhmg3OK6mqhX2mqzP2+sCjkyis1UYXx 7XNJjIllzJrWcYaO+o0qYMpdEAXTewtxuvwYxoch6p5DiGRvD2DD0RkXNIBLWWgCAXHS zd6eLfLcINORPHhl2LGCagB57tfrM52EJ2y07wdi2LvTKElEOESEAwWwaWbj9oV+CdNL dt1ZB3e9gqKXMEkqvIcaguR6BGGE7+mMktLHhf+/DCF8ii78I4OT4iEfwbTEBBh1CGgc el7w== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z33si9759769edb.183.2019.11.26.20.59.31; Tue, 26 Nov 2019 21:00:33 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726694AbfK0EyP (ORCPT + 99 others); Tue, 26 Nov 2019 23:54:15 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:61740 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726548AbfK0EyO (ORCPT ); Tue, 26 Nov 2019 23:54:14 -0500 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAR4ldD0123482 for ; Tue, 26 Nov 2019 23:54:13 -0500 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0a-001b2d01.pphosted.com with ESMTP id 2whcxns3n4-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 26 Nov 2019 23:54:13 -0500 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 27 Nov 2019 04:54:11 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp07.uk.ibm.com (192.168.101.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 27 Nov 2019 04:54:09 -0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id xAR4s8vJ37945446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Nov 2019 04:54:08 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4C4D15207A; Wed, 27 Nov 2019 04:54:08 +0000 (GMT) Received: from localhost.localdomain (unknown [9.124.35.154]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 20BB952050; Wed, 27 Nov 2019 04:54:06 +0000 (GMT) Subject: Re: [PATCH v3 2/4] powerpc/fadump: reorganize /sys/kernel/fadump_* sysfs files To: =?UTF-8?Q?Michal_Such=c3=a1nek?= Cc: corbet@lwn.net, mahesh@linux.vnet.ibm.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, hbathini@linux.ibm.com References: <20191109122339.20484-1-sourabhjain@linux.ibm.com> <20191109122339.20484-3-sourabhjain@linux.ibm.com> <20191109125933.GF1384@kitsune.suse.cz> <8c1ec297-0c34-12de-2528-be436697215a@linux.ibm.com> <20191124184059.GP11661@kitsune.suse.cz> From: Sourabh Jain Date: Wed, 27 Nov 2019 10:24:06 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20191124184059.GP11661@kitsune.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 19112704-0028-0000-0000-000003C07E12 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19112704-0029-0000-0000-0000248382FB Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-26_08:2019-11-26,2019-11-26 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 mlxscore=0 phishscore=0 lowpriorityscore=0 priorityscore=1501 suspectscore=0 bulkscore=0 impostorscore=0 spamscore=0 clxscore=1015 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911270037 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/25/19 12:10 AM, Michal Suchánek wrote: > On Sat, Nov 16, 2019 at 08:07:29PM +0530, Sourabh Jain wrote: >> >> >> On 11/9/19 6:29 PM, Michal Suchánek wrote: >>> On Sat, Nov 09, 2019 at 05:53:37PM +0530, Sourabh Jain wrote: >>>> As the number of FADump sysfs files increases it is hard to manage all of >>>> them inside /sys/kernel directory. It's better to have all the FADump >>>> related sysfs files in a dedicated directory /sys/kernel/fadump. But in >>>> order to maintain the backward compatibility the /sys/kernel/fadump_* >>>> sysfs files are replicated inside /sys/kernel/fadump/ and eventually get >>>> removed in future. >>>> >>>> As the FADump sysfs files are now part of dedicated directory there is no >>>> need to prefix their name with fadump_, hence sysfs file names are also >>>> updated. For example fadump_enabled sysfs file is now referred as enabled. >>>> >>>> Also consolidate ABI documentation for all the FADump sysfs files in a >>>> single file Documentation/ABI/testing/sysfs-kernel-fadump. >>>> >>>> Signed-off-by: Sourabh Jain >>>> --- >>>> Documentation/ABI/testing/sysfs-kernel-fadump | 41 +++++++++++++++++++ >>>> arch/powerpc/kernel/fadump.c | 38 +++++++++++++++++ >>>> arch/powerpc/platforms/powernv/opal-core.c | 10 +++-- >>>> 3 files changed, 86 insertions(+), 3 deletions(-) >>>> create mode 100644 Documentation/ABI/testing/sysfs-kernel-fadump >>>> >>>> diff --git a/Documentation/ABI/testing/sysfs-kernel-fadump b/Documentation/ABI/testing/sysfs-kernel-fadump >>>> new file mode 100644 >>>> index 000000000000..a77f1a5ba389 >>>> --- /dev/null >>>> +++ b/Documentation/ABI/testing/sysfs-kernel-fadump >>>> @@ -0,0 +1,41 @@ >>>> +What: /sys/kernel/fadump/* >>>> +Date: Nov 2019 >>>> +Contact: linuxppc-dev@lists.ozlabs.org >>>> +Description: >>>> + The /sys/kernel/fadump/* is a collection of FADump sysfs >>>> + file provide information about the configuration status >>>> + of Firmware Assisted Dump (FADump). >>>> + >>>> +What: /sys/kernel/fadump/enabled >>>> +Date: Nov 2019 >>>> +Contact: linuxppc-dev@lists.ozlabs.org >>>> +Description: read only >>>> + Primarily used to identify whether the FADump is enabled in >>>> + the kernel or not. >>>> +User: Kdump service >>>> + >>>> +What: /sys/kernel/fadump/registered >>>> +Date: Nov 2019 >>>> +Contact: linuxppc-dev@lists.ozlabs.org >>>> +Description: read/write >>>> + Helps to control the dump collect feature from userspace. >>>> + Setting 1 to this file enables the system to collect the >>>> + dump and 0 to disable it. >>>> +User: Kdump service >>>> + >>>> +What: /sys/kernel/fadump/release_mem >>>> +Date: Nov 2019 >>>> +Contact: linuxppc-dev@lists.ozlabs.org >>>> +Description: write only >>>> + This is a special sysfs file and only available when >>>> + the system is booted to capture the vmcore using FADump. >>>> + It is used to release the memory reserved by FADump to >>>> + save the crash dump. >>>> + >>>> +What: /sys/kernel/fadump/release_opalcore >>>> +Date: Nov 2019 >>>> +Contact: linuxppc-dev@lists.ozlabs.org >>>> +Description: write only >>>> + The sysfs file is available when the system is booted to >>>> + collect the dump on OPAL based machine. It used to release >>>> + the memory used to collect the opalcore. >>>> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c >>>> index ed59855430b9..a9591def0c84 100644 >>>> --- a/arch/powerpc/kernel/fadump.c >>>> +++ b/arch/powerpc/kernel/fadump.c >>>> @@ -1418,6 +1418,9 @@ static int fadump_region_show(struct seq_file *m, void *private) >>>> return 0; >>>> } >>>> >>>> +struct kobject *fadump_kobj; >>>> +EXPORT_SYMBOL_GPL(fadump_kobj); >>>> + >>>> static struct kobj_attribute fadump_release_attr = __ATTR(fadump_release_mem, >>>> 0200, NULL, >>>> fadump_release_memory_store); >>>> @@ -1428,6 +1431,16 @@ static struct kobj_attribute fadump_register_attr = __ATTR(fadump_registered, >>>> 0644, fadump_register_show, >>>> fadump_register_store); >>>> >>>> +static struct kobj_attribute release_attr = __ATTR(release_mem, >>>> + 0200, NULL, >>>> + fadump_release_memory_store); >>>> +static struct kobj_attribute enable_attr = __ATTR(enabled, >>>> + 0444, fadump_enabled_show, >>>> + NULL); >>>> +static struct kobj_attribute register_attr = __ATTR(registered, >>>> + 0644, fadump_register_show, >>>> + fadump_register_store); >>>> + >>>> DEFINE_SHOW_ATTRIBUTE(fadump_region); >>>> >>>> static void fadump_init_files(void) >>>> @@ -1435,6 +1448,11 @@ static void fadump_init_files(void) >>>> struct dentry *debugfs_file; >>>> int rc = 0; >>>> >>>> + fadump_kobj = kobject_create_and_add("fadump", kernel_kobj); >>>> + if (!fadump_kobj) { >>>> + pr_err("failed to create fadump kobject\n"); >>>> + return; >>>> + } >>>> rc = sysfs_create_file(kernel_kobj, &fadump_attr.attr); >>>> if (rc) >>>> printk(KERN_ERR "fadump: unable to create sysfs file" >>>> @@ -1458,6 +1476,26 @@ static void fadump_init_files(void) >>>> printk(KERN_ERR "fadump: unable to create sysfs file" >>>> " fadump_release_mem (%d)\n", rc); >>>> } >>>> + /* Replicating the following sysfs attributes under FADump kobject. >>>> + * >>>> + * - fadump_enabled -> enabled >>>> + * - fadump_registered -> registered >>>> + * - fadump_release_mem -> release_mem >>>> + */ >>>> + rc = sysfs_create_file(fadump_kobj, &enable_attr.attr); >>>> + if (rc) >>>> + pr_err("unable to create enabled sysfs file (%d)\n", >>>> + rc); >>>> + rc = sysfs_create_file(fadump_kobj, ®ister_attr.attr); >>>> + if (rc) >>>> + pr_err("unable to create registered sysfs file (%d)\n", >>>> + rc); >>>> + if (fw_dump.dump_active) { >>>> + rc = sysfs_create_file(fadump_kobj, &release_attr.attr); >>>> + if (rc) >>>> + pr_err("unable to create release_mem sysfs file (%d)\n", >>>> + rc); >>>> + } >>>> return; >>>> } >>> Hello, >>> >> >> I’m so sorry for taking this long to write you back. >> >>> wouldn't it make more sense to create the files in the new location and >>> add a symlink at the old location? >> >> There are APIs which allow to create a symlink for an entire kobject but >> I did not find a way to create symlink of an individual sysfs file. >> >> Do you have any approach in mind to achieve the same? > > There is at least one example of plain symlink: > > find /sys -type l -xtype f > /sys/kernel/security/evm Yes, there are APIs available in debugfs and securityfs that allow creatinga symlink of sysfs files. But I did not find a generic API at sysfs level tocreate symlink. Let's wait for others to put in their view on this. Meanwhile, I'll start exploring how we can replace the older FADump sysfs files with symlink. Thanks, Sourabh Jain