Message ID | 20221128151612.1786122-1-yangyingliang@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp5748014wrr; Mon, 28 Nov 2022 07:24:54 -0800 (PST) X-Google-Smtp-Source: AA0mqf4sNcIzhhg3DP7j8KXjVH9YxQIVhKV90iy30xjRx+iDSYkbCB4uqxZB/9fGNJw/9y1bhkDK X-Received: by 2002:a17:906:40d7:b0:7be:12aa:6440 with SMTP id a23-20020a17090640d700b007be12aa6440mr9045379ejk.393.1669649093954; Mon, 28 Nov 2022 07:24:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669649093; cv=none; d=google.com; s=arc-20160816; b=WSo1WfDe2zTjErgCiYm2xubG8FD4d57EOleC9Z725M4UbV3V8iNEksPiqIAKxV0MVj sPzpTShvyuuJ9kLiCHed7otnFi9AeHOU5ElGXaLE4bOfHLwtFeVcAQckqrtvuY+2dDEj U1cFHW+1ZowIXTO7XGxfAO6RDgHH/SUZBjrndqDHxqdBLb8jCMDWA6rAz98++3CQaF67 /mBhIddG4NqFzvBTr24QSuiUQJaRHzYKQhHejWmz3lcLmlJlAkzCW7936oqhQclUmLxo d5jnNcwX0OkUfqv8ZZJouK/54ZnVNyGYE6rQgYXhXU86C6Tbi7dvAgKghgA/Hu7gVU/d erpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:to:from; bh=UJu3T8qYfFgSnnOMbthPYc8HS2kQTiDYnItdt2VwgqA=; b=tIO+r2KfJ9tUWxVG+8HRG05UKx44MR2qg/yiWMpTDYFHqxEAFHoVXx48UWL3PaVSUJ uG1DL2L3hiqQL8NNz0EYCpDZGFry0GMccnhTMRzTjSltclpnAntZ4oTjVFanl4eSpcVZ 28odWGucDSQ6DQuDgW4kR7ct4XUWB1Hud0RK7Rpr7T5NzCavsPVb761aDhDOb1KPpauX 6SPxSeM46mkODsTvUM6rhh/d5bx5DMc2rleOeD+qOL/jGq8tan+Q+IvB7Dc0JBInuyDN CA94eHs3eap+ECke751H6i1Pn+n7BFQEUKVzkJnhQs6J8/XHvdolG66lX6XBcIGm693u ThcA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qo14-20020a170907874e00b0078849a014e9si8410420ejc.196.2022.11.28.07.24.29; Mon, 28 Nov 2022 07:24:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231617AbiK1PSR (ORCPT <rfc822;gah0developer@gmail.com> + 99 others); Mon, 28 Nov 2022 10:18:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230092AbiK1PSQ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 28 Nov 2022 10:18:16 -0500 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1FFF2A45C for <linux-kernel@vger.kernel.org>; Mon, 28 Nov 2022 07:18:14 -0800 (PST) Received: from dggpemm500022.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4NLTbt6PdBzHw7m; Mon, 28 Nov 2022 23:17:30 +0800 (CST) Received: from dggpemm500007.china.huawei.com (7.185.36.183) by dggpemm500022.china.huawei.com (7.185.36.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 28 Nov 2022 23:18:11 +0800 Received: from huawei.com (10.175.103.91) by dggpemm500007.china.huawei.com (7.185.36.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 28 Nov 2022 23:18:11 +0800 From: Yang Yingliang <yangyingliang@huawei.com> To: <tglx@linutronix.de>, <kraig@google.com>, <linux-kernel@vger.kernel.org>, <gregkh@linuxfoundation.org> Subject: [PATCH v2] genirq/irqdesc: fix WARNING in irq_sysfs_del() Date: Mon, 28 Nov 2022 23:16:12 +0800 Message-ID: <20221128151612.1786122-1-yangyingliang@huawei.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.103.91] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500007.china.huawei.com (7.185.36.183) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750753968192432471?= X-GMAIL-MSGID: =?utf-8?q?1750753968192432471?= |
Series |
[v2] genirq/irqdesc: fix WARNING in irq_sysfs_del()
|
|
Commit Message
Yang Yingliang
Nov. 28, 2022, 3:16 p.m. UTC
I got the lots of WARNING report when doing fault injection test:
kernfs: can not remove 'chip_name', no directory
WARNING: CPU: 0 PID: 253 at fs/kernfs/dir.c:1616 kernfs_remove_by_name_ns+0xce/0xe0
RIP: 0010:kernfs_remove_by_name_ns+0xce/0xe0
Call Trace:
<TASK>
remove_files.isra.1+0x3f/0xb0
sysfs_remove_group+0x68/0xe0
sysfs_remove_groups+0x41/0x70
__kobject_del+0x45/0xc0
kobject_del+0x29/0x40
free_desc+0x42/0x70
irq_free_descs+0x5e/0x90
kernfs: can not remove 'hwirq', no directory
WARNING: CPU: 0 PID: 253 at fs/kernfs/dir.c:1616 kernfs_remove_by_name_ns+0xce/0xe0
RIP: 0010:kernfs_remove_by_name_ns+0xce/0xe0
Call Trace:
<TASK>
remove_files.isra.1+0x3f/0xb0
sysfs_remove_group+0x68/0xe0
sysfs_remove_groups+0x41/0x70
__kobject_del+0x45/0xc0
kobject_del+0x29/0x40
free_desc+0x42/0x70
irq_free_descs+0x5e/0x90
If irq_sysfs_add() fails in alloc_descs(), the directory of interrupt
informations is not added to sysfs, it causes the WARNINGs when removing
the information files. Add 'sysfs_added' field in struct irq_desc to
indicate if it is added, and check it before calling kobject_del() to
avoid these WARNINGs.
Fixes: ecb3f394c5db ("genirq: Expose interrupt information through sysfs")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
---
v1 -> v2:
Don't use state_in_sysfs, introduce 'sysfs_added' to indicate if it is added.
---
include/linux/irqdesc.h | 1 +
kernel/irq/irqdesc.c | 7 +++++--
2 files changed, 6 insertions(+), 2 deletions(-)
Comments
On Mon, Nov 28, 2022 at 11:16:12PM +0800, Yang Yingliang wrote: > I got the lots of WARNING report when doing fault injection test: > > kernfs: can not remove 'chip_name', no directory > WARNING: CPU: 0 PID: 253 at fs/kernfs/dir.c:1616 kernfs_remove_by_name_ns+0xce/0xe0 > RIP: 0010:kernfs_remove_by_name_ns+0xce/0xe0 > Call Trace: > <TASK> > remove_files.isra.1+0x3f/0xb0 > sysfs_remove_group+0x68/0xe0 > sysfs_remove_groups+0x41/0x70 > __kobject_del+0x45/0xc0 > kobject_del+0x29/0x40 > free_desc+0x42/0x70 > irq_free_descs+0x5e/0x90 > > kernfs: can not remove 'hwirq', no directory > WARNING: CPU: 0 PID: 253 at fs/kernfs/dir.c:1616 kernfs_remove_by_name_ns+0xce/0xe0 > RIP: 0010:kernfs_remove_by_name_ns+0xce/0xe0 > Call Trace: > <TASK> > remove_files.isra.1+0x3f/0xb0 > sysfs_remove_group+0x68/0xe0 > sysfs_remove_groups+0x41/0x70 > __kobject_del+0x45/0xc0 > kobject_del+0x29/0x40 > free_desc+0x42/0x70 > irq_free_descs+0x5e/0x90 > > If irq_sysfs_add() fails in alloc_descs(), the directory of interrupt > informations is not added to sysfs, it causes the WARNINGs when removing > the information files. Add 'sysfs_added' field in struct irq_desc to > indicate if it is added, and check it before calling kobject_del() to > avoid these WARNINGs. > > Fixes: ecb3f394c5db ("genirq: Expose interrupt information through sysfs") > Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> > --- > v1 -> v2: > Don't use state_in_sysfs, introduce 'sysfs_added' to indicate if it is added. > --- > include/linux/irqdesc.h | 1 + > kernel/irq/irqdesc.c | 7 +++++-- > 2 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h > index 844a8e30e6de..fec0f3946a34 100644 > --- a/include/linux/irqdesc.h > +++ b/include/linux/irqdesc.h > @@ -97,6 +97,7 @@ struct irq_desc { > #ifdef CONFIG_SPARSE_IRQ > struct rcu_head rcu; > struct kobject kobj; > + bool sysfs_added; > #endif > struct mutex request_mutex; > int parent_irq; > diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c > index a91f9001103c..9bf74d11bad5 100644 > --- a/kernel/irq/irqdesc.c > +++ b/kernel/irq/irqdesc.c > @@ -292,6 +292,8 @@ static void irq_sysfs_add(int irq, struct irq_desc *desc) > */ > if (kobject_add(&desc->kobj, irq_kobj_base, "%d", irq)) > pr_warn("Failed to add kobject for irq %d\n", irq); > + else > + desc->sysfs_added = true; Wait, no. Why are you just not properly failing and unwinding here? Why do you need a special flag just to say "sysfs worked" or not unlike all other users of kobjects. Fix this up properly please. thanks, greg k-h
On Mon, Nov 28 2022 at 18:20, Greg KH wrote: > On Mon, Nov 28, 2022 at 11:16:12PM +0800, Yang Yingliang wrote: >> @@ -292,6 +292,8 @@ static void irq_sysfs_add(int irq, struct irq_desc *desc) >> */ >> if (kobject_add(&desc->kobj, irq_kobj_base, "%d", irq)) >> pr_warn("Failed to add kobject for irq %d\n", irq); >> + else >> + desc->sysfs_added = true; > > Wait, no. Why are you just not properly failing and unwinding here? There is an issue here. sysfs is not yet available when the first interrupts are allocated. So we add the sysfs files late in the boot. So what can we do if that fails? Unwind the boot process? :) Sure we can fail after sysfs has been initialized, but that's inconsistent at best and we need some special treatment for the late add anyway. I agree that this is not pretty, but the resulting choices are all but pretty. Thanks, tglx
On 2022/11/29 1:20, Greg KH wrote: > On Mon, Nov 28, 2022 at 11:16:12PM +0800, Yang Yingliang wrote: >> I got the lots of WARNING report when doing fault injection test: >> >> kernfs: can not remove 'chip_name', no directory >> WARNING: CPU: 0 PID: 253 at fs/kernfs/dir.c:1616 kernfs_remove_by_name_ns+0xce/0xe0 >> RIP: 0010:kernfs_remove_by_name_ns+0xce/0xe0 >> Call Trace: >> <TASK> >> remove_files.isra.1+0x3f/0xb0 >> sysfs_remove_group+0x68/0xe0 >> sysfs_remove_groups+0x41/0x70 >> __kobject_del+0x45/0xc0 >> kobject_del+0x29/0x40 >> free_desc+0x42/0x70 >> irq_free_descs+0x5e/0x90 >> >> kernfs: can not remove 'hwirq', no directory >> WARNING: CPU: 0 PID: 253 at fs/kernfs/dir.c:1616 kernfs_remove_by_name_ns+0xce/0xe0 >> RIP: 0010:kernfs_remove_by_name_ns+0xce/0xe0 >> Call Trace: >> <TASK> >> remove_files.isra.1+0x3f/0xb0 >> sysfs_remove_group+0x68/0xe0 >> sysfs_remove_groups+0x41/0x70 >> __kobject_del+0x45/0xc0 >> kobject_del+0x29/0x40 >> free_desc+0x42/0x70 >> irq_free_descs+0x5e/0x90 >> >> If irq_sysfs_add() fails in alloc_descs(), the directory of interrupt >> informations is not added to sysfs, it causes the WARNINGs when removing >> the information files. Add 'sysfs_added' field in struct irq_desc to >> indicate if it is added, and check it before calling kobject_del() to >> avoid these WARNINGs. >> >> Fixes: ecb3f394c5db ("genirq: Expose interrupt information through sysfs") >> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> >> --- >> v1 -> v2: >> Don't use state_in_sysfs, introduce 'sysfs_added' to indicate if it is added. >> --- >> include/linux/irqdesc.h | 1 + >> kernel/irq/irqdesc.c | 7 +++++-- >> 2 files changed, 6 insertions(+), 2 deletions(-) >> >> diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h >> index 844a8e30e6de..fec0f3946a34 100644 >> --- a/include/linux/irqdesc.h >> +++ b/include/linux/irqdesc.h >> @@ -97,6 +97,7 @@ struct irq_desc { >> #ifdef CONFIG_SPARSE_IRQ >> struct rcu_head rcu; >> struct kobject kobj; >> + bool sysfs_added; >> #endif >> struct mutex request_mutex; >> int parent_irq; >> diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c >> index a91f9001103c..9bf74d11bad5 100644 >> --- a/kernel/irq/irqdesc.c >> +++ b/kernel/irq/irqdesc.c >> @@ -292,6 +292,8 @@ static void irq_sysfs_add(int irq, struct irq_desc *desc) >> */ >> if (kobject_add(&desc->kobj, irq_kobj_base, "%d", irq)) >> pr_warn("Failed to add kobject for irq %d\n", irq); >> + else >> + desc->sysfs_added = true; > Wait, no. Why are you just not properly failing and unwinding here? We can not call kobject_put() here, it will free the 'desc' in irq_kobj_release(), the irq is still in use and the 'desc' should be freed in free_desc(), so the failure handled in irq_sysfs_del(). If irq_sysfs_add() fails, it does nothing except print message, we don't know if it's added successfully while calling irq_sysfs_del(), so I introduced a filed to store the return status that can be used in irq_sysfs_add(). alloc_descs() irq_sysfs_add(desc) <-- it's failed and does nothing except print message irq_free_descs() free_desc() irq_sysfs_del(desc) <-- it doesn't know irq_sysfs_add() is failed. delayed_free_desc() kfree(desc) I this case, If dont' use a flag, I can not figure out a better way to let irq_sysfs_del() know it's added failed. Thanks, Yang > Why do you need a special flag just to say "sysfs worked" or not unlike > all other users of kobjects. > > Fix this up properly please. > > thanks, > > greg k-h > .
On Mon, Nov 28, 2022 at 07:55:17PM +0100, Thomas Gleixner wrote: > On Mon, Nov 28 2022 at 18:20, Greg KH wrote: > > On Mon, Nov 28, 2022 at 11:16:12PM +0800, Yang Yingliang wrote: > >> @@ -292,6 +292,8 @@ static void irq_sysfs_add(int irq, struct irq_desc *desc) > >> */ > >> if (kobject_add(&desc->kobj, irq_kobj_base, "%d", irq)) > >> pr_warn("Failed to add kobject for irq %d\n", irq); > >> + else > >> + desc->sysfs_added = true; > > > > Wait, no. Why are you just not properly failing and unwinding here? > > There is an issue here. > > sysfs is not yet available when the first interrupts are allocated. So > we add the sysfs files late in the boot. > > So what can we do if that fails? Unwind the boot process? :) > > Sure we can fail after sysfs has been initialized, but that's > inconsistent at best and we need some special treatment for the late add > anyway. > > I agree that this is not pretty, but the resulting choices are all but > pretty. Ah, ok, that makes more sense. In this case, yes, the flag should be fine to have. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h index 844a8e30e6de..fec0f3946a34 100644 --- a/include/linux/irqdesc.h +++ b/include/linux/irqdesc.h @@ -97,6 +97,7 @@ struct irq_desc { #ifdef CONFIG_SPARSE_IRQ struct rcu_head rcu; struct kobject kobj; + bool sysfs_added; #endif struct mutex request_mutex; int parent_irq; diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c index a91f9001103c..9bf74d11bad5 100644 --- a/kernel/irq/irqdesc.c +++ b/kernel/irq/irqdesc.c @@ -292,6 +292,8 @@ static void irq_sysfs_add(int irq, struct irq_desc *desc) */ if (kobject_add(&desc->kobj, irq_kobj_base, "%d", irq)) pr_warn("Failed to add kobject for irq %d\n", irq); + else + desc->sysfs_added = true; } } @@ -299,11 +301,12 @@ static void irq_sysfs_del(struct irq_desc *desc) { /* * If irq_sysfs_init() has not yet been invoked (early boot), then - * irq_kobj_base is NULL and the descriptor was never added. + * irq_kobj_base is NULL or kobject_add() fails, the descriptor was + * never added. * kobject_del() complains about a object with no parent, so make * it conditional. */ - if (irq_kobj_base) + if (desc->sysfs_added) kobject_del(&desc->kobj); }