Message ID | 20221112093939.616270-1-liushixin2@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp1181091wru; Sat, 12 Nov 2022 00:57:50 -0800 (PST) X-Google-Smtp-Source: AA0mqf6swUoimfwepzWtpiX9TSd32iNFU/kyGA+Gtvm9TkbijOaPGW3ALmFHolzwoSIuN1NRNfS4 X-Received: by 2002:a17:906:4ed8:b0:7ae:d58b:30f8 with SMTP id i24-20020a1709064ed800b007aed58b30f8mr3225771ejv.564.1668243469972; Sat, 12 Nov 2022 00:57:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668243469; cv=none; d=google.com; s=arc-20160816; b=TybXF+WHEUl3gaGK+ywlpB7Co+zj7H666r9CqD5rZdxzJjp6njc8GYwdTOpBtZHDNO Fzp0cP2Z+JNN63gJYWAqGPo+8lQxI8aC620ZasNfmuy/UWFU6yXdUluQpCpZN46uHduo 0RYf6ppK/RX7Mv+icMAFm5j+L5t5l6lMFJoRKOouAgpOtjwRH11IvT35CmCkD/8kRgg6 iJ9ToDg5HK79kISKsRm1ganXZWzZWT5XMcTKOTmMrxdzmF9w1tqwr1a/Z3gu1U2fs+i5 p9IpX/OTZ16WquKoVIInQQrioD9D/qHFWJcnqzQgqFNfNWVYQ0moEqI+hgmjb1EB9Zdl A6HA== 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:cc:to:from; bh=CiMAQeVlSFrvSos/5RMxNpj9Gear+Z26DBW7cUQD/Bo=; b=XRXIy2shLlXN248qUACivh7+o/eKwTbgHeA7uDyrtyQ4IjffxU5ddc9pHn7T/15tzm sluT35/qq32t5FBCPOcVytWGKsdjS1nBulBKbIQm8uVTAjaQZJiJblJW//PjjvwChaj1 YYLROw1S7bugtxJU8b8dXQLW1+b1acqetrHdegsBnz62wvQNK9bPVSDXNjSG8Bc1PGWb 38MeIzJ41nnMrTeJYcehS8ALQJ4cwjqYkyPwQqXCuIGsQ276MSqEeMQd6p5Zy8lcXGLf Vh0QU6p0bRYDreAxae5qoejJs8ckKsjHvvLzzc0aENTA2sZV+7AwH+G5ligmFHS3i0b5 57+A== 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 d8-20020a056402400800b0045907cec72dsi4877602eda.320.2022.11.12.00.57.25; Sat, 12 Nov 2022 00:57:49 -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 S233552AbiKLIwc (ORCPT <rfc822;winker.wchi@gmail.com> + 99 others); Sat, 12 Nov 2022 03:52:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230257AbiKLIwa (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 12 Nov 2022 03:52:30 -0500 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FA452F38D for <linux-kernel@vger.kernel.org>; Sat, 12 Nov 2022 00:52:28 -0800 (PST) Received: from dggpemm500021.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4N8TpR1k7NzHtt6; Sat, 12 Nov 2022 16:51:59 +0800 (CST) Received: from dggpemm100009.china.huawei.com (7.185.36.113) by dggpemm500021.china.huawei.com (7.185.36.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Sat, 12 Nov 2022 16:52:26 +0800 Received: from huawei.com (10.175.113.32) by dggpemm100009.china.huawei.com (7.185.36.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Sat, 12 Nov 2022 16:52:26 +0800 From: Liu Shixin <liushixin2@huawei.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Thomas Gleixner <tglx@linutronix.de>, "Rafael J . Wysocki" <rafael@kernel.org> CC: <linux-kernel@vger.kernel.org>, Liu Shixin <liushixin2@huawei.com> Subject: [PATCH] genirq/irqdesc: hide illegible sysfs warning of kobject_del() Date: Sat, 12 Nov 2022 17:39:39 +0800 Message-ID: <20221112093939.616270-1-liushixin2@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.113.32] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm100009.china.huawei.com (7.185.36.113) 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?1749280065073493180?= X-GMAIL-MSGID: =?utf-8?q?1749280065073493180?= |
Series |
genirq/irqdesc: hide illegible sysfs warning of kobject_del()
|
|
Commit Message
Liu Shixin
Nov. 12, 2022, 9:39 a.m. UTC
If irq_sysfs_add() failed, system will report a warning but don't call
kobject_put() to release the descriptor. Then in irq_sysfs_del(), we
continue to call kobject_del(). In such situation, kobject_del() will
complains about a object with no parent like this:
kernfs: can not remove 'actions', no directory
WARNING: CPU: 0 PID: 277 at fs/kernfs/dir.c:1615 kernfs_remove_by_name_ns+0xd5/0xe0
[...]
Call Trace:
<TASK>
remove_files.isra.0+0x3f/0xb0
sysfs_remove_group+0x68/0xe0
sysfs_remove_groups+0x41/0x70
__kobject_del+0x45/0xc0
kobject_del+0x2a/0x40
free_desc+0x44/0x70
irq_free_descs+0x5d/0x90
[...]
Use kobj->state_in_sysfs to check whether kobject is added succeed. And
if not, we should not call kobject_del().
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
---
kernel/irq/irqdesc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Comments
On Sat, Nov 12, 2022 at 05:39:39PM +0800, Liu Shixin wrote: > If irq_sysfs_add() failed, system will report a warning but don't call > kobject_put() to release the descriptor. I can not parse this sentance :( > Then in irq_sysfs_del(), we continue to call kobject_del(). In such > situation, kobject_del() will complains about a object with no parent > like this: Then we should not be calling irq_sysfs_del() if the call failed. That is the real fix here. > > kernfs: can not remove 'actions', no directory > WARNING: CPU: 0 PID: 277 at fs/kernfs/dir.c:1615 kernfs_remove_by_name_ns+0xd5/0xe0 > [...] > Call Trace: > <TASK> > remove_files.isra.0+0x3f/0xb0 > sysfs_remove_group+0x68/0xe0 > sysfs_remove_groups+0x41/0x70 > __kobject_del+0x45/0xc0 > kobject_del+0x2a/0x40 > free_desc+0x44/0x70 > irq_free_descs+0x5d/0x90 > [...] > > Use kobj->state_in_sysfs to check whether kobject is added succeed. And > if not, we should not call kobject_del(). That does not describe what you are doing here at all. > > Signed-off-by: Liu Shixin <liushixin2@huawei.com> > --- > kernel/irq/irqdesc.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c > index a91f9001103c..a820d96210d4 100644 > --- a/kernel/irq/irqdesc.c > +++ b/kernel/irq/irqdesc.c > @@ -300,10 +300,11 @@ 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. > + * And the descriptor may be added failed. > * kobject_del() complains about a object with no parent, so make > * it conditional. > */ > - if (irq_kobj_base) > + if (irq_kobj_base && desc->kobj.parent) How would the parent be NULL? Parent devices always stick around until the child is removed, otherwise something is really wrong here. You should never have to look at the parent. thanks, greg k-h
On 2022/11/12 16:59, Greg Kroah-Hartman wrote: > On Sat, Nov 12, 2022 at 05:39:39PM +0800, Liu Shixin wrote: >> If irq_sysfs_add() failed, system will report a warning but don't call >> kobject_put() to release the descriptor. > I can not parse this sentance :( irq_sysfs_add() call kobject_add(). If kobject_add() failed, will print "Failed to add kobject for irq". But not call kobject_put(). > >> Then in irq_sysfs_del(), we continue to call kobject_del(). In such >> situation, kobject_del() will complains about a object with no parent >> like this: > Then we should not be calling irq_sysfs_del() if the call failed. That > is the real fix here. If so, should I add a variable to record whether kobject has alreadly added or not? >> kernfs: can not remove 'actions', no directory >> WARNING: CPU: 0 PID: 277 at fs/kernfs/dir.c:1615 kernfs_remove_by_name_ns+0xd5/0xe0 >> [...] >> Call Trace: >> <TASK> >> remove_files.isra.0+0x3f/0xb0 >> sysfs_remove_group+0x68/0xe0 >> sysfs_remove_groups+0x41/0x70 >> __kobject_del+0x45/0xc0 >> kobject_del+0x2a/0x40 >> free_desc+0x44/0x70 >> irq_free_descs+0x5d/0x90 >> [...] >> >> Use kobj->state_in_sysfs to check whether kobject is added succeed. And >> if not, we should not call kobject_del(). > That does not describe what you are doing here at all. Sorry, I forget to update... > >> Signed-off-by: Liu Shixin <liushixin2@huawei.com> >> --- >> kernel/irq/irqdesc.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c >> index a91f9001103c..a820d96210d4 100644 >> --- a/kernel/irq/irqdesc.c >> +++ b/kernel/irq/irqdesc.c >> @@ -300,10 +300,11 @@ 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. >> + * And the descriptor may be added failed. >> * kobject_del() complains about a object with no parent, so make >> * it conditional. >> */ >> - if (irq_kobj_base) >> + if (irq_kobj_base && desc->kobj.parent) > How would the parent be NULL? Parent devices always stick around until > the child is removed, otherwise something is really wrong here. You > should never have to look at the parent. irq_sysfs_add() call kobject_add(). If kobject_add() failed, the parent will be NULL. You can find the same check of kobj->parent in cpuid_cpu_offline(). thanks, Liu Shixin . > > thanks, > > greg k-h > . >
On Sat, Nov 12, 2022 at 05:19:50PM +0800, Liu Shixin wrote: > > > On 2022/11/12 16:59, Greg Kroah-Hartman wrote: > > On Sat, Nov 12, 2022 at 05:39:39PM +0800, Liu Shixin wrote: > >> If irq_sysfs_add() failed, system will report a warning but don't call > >> kobject_put() to release the descriptor. > > I can not parse this sentance :( > irq_sysfs_add() call kobject_add(). If kobject_add() failed, will print "Failed to add kobject for irq". > But not call kobject_put(). Then fix that. > >> Then in irq_sysfs_del(), we continue to call kobject_del(). In such > >> situation, kobject_del() will complains about a object with no parent > >> like this: > > Then we should not be calling irq_sysfs_del() if the call failed. That > > is the real fix here. > If so, should I add a variable to record whether kobject has alreadly added or not? The code itself knows what just failed, handle the error case there properly. > >> kernfs: can not remove 'actions', no directory > >> WARNING: CPU: 0 PID: 277 at fs/kernfs/dir.c:1615 kernfs_remove_by_name_ns+0xd5/0xe0 > >> [...] > >> Call Trace: > >> <TASK> > >> remove_files.isra.0+0x3f/0xb0 > >> sysfs_remove_group+0x68/0xe0 > >> sysfs_remove_groups+0x41/0x70 > >> __kobject_del+0x45/0xc0 > >> kobject_del+0x2a/0x40 > >> free_desc+0x44/0x70 > >> irq_free_descs+0x5d/0x90 > >> [...] > >> > >> Use kobj->state_in_sysfs to check whether kobject is added succeed. And > >> if not, we should not call kobject_del(). > > That does not describe what you are doing here at all. > Sorry, I forget to update... > > > >> Signed-off-by: Liu Shixin <liushixin2@huawei.com> > >> --- > >> kernel/irq/irqdesc.c | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >> diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c > >> index a91f9001103c..a820d96210d4 100644 > >> --- a/kernel/irq/irqdesc.c > >> +++ b/kernel/irq/irqdesc.c > >> @@ -300,10 +300,11 @@ 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. > >> + * And the descriptor may be added failed. > >> * kobject_del() complains about a object with no parent, so make > >> * it conditional. > >> */ > >> - if (irq_kobj_base) > >> + if (irq_kobj_base && desc->kobj.parent) > > How would the parent be NULL? Parent devices always stick around until > > the child is removed, otherwise something is really wrong here. You > > should never have to look at the parent. > irq_sysfs_add() call kobject_add(). If kobject_add() failed, the parent will be NULL. > You can find the same check of kobj->parent in cpuid_cpu_offline(). And it is wrong there as well. Do not copy bad patterns please. thanks, greg k-h
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c index a91f9001103c..a820d96210d4 100644 --- a/kernel/irq/irqdesc.c +++ b/kernel/irq/irqdesc.c @@ -300,10 +300,11 @@ 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. + * And the descriptor may be added failed. * kobject_del() complains about a object with no parent, so make * it conditional. */ - if (irq_kobj_base) + if (irq_kobj_base && desc->kobj.parent) kobject_del(&desc->kobj); }