Message ID | 20221111065807.3278713-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 l7csp568482wru; Thu, 10 Nov 2022 22:11:52 -0800 (PST) X-Google-Smtp-Source: AA0mqf5DtIEYCc/eplLrBN0oSmCQMAC/ytoEqJn/Y9yDplzk0QH3Xcy0EjXrY0NNAwc9+RwVJJzM X-Received: by 2002:a17:902:9893:b0:188:547d:b15e with SMTP id s19-20020a170902989300b00188547db15emr1199742plp.50.1668147111983; Thu, 10 Nov 2022 22:11:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668147111; cv=none; d=google.com; s=arc-20160816; b=FDZmNaugckBaNp1emWie3EhQJS0QyDhdHIpDWFmToedEo9fNl//J62zH34ZxLs9Rmv XWx1dEpdbDNQ3XlI3r1G+qmjb8y4u+CQvO16PMQt2v6v/a0gSXT9zkdWkymWVBXUkpNS 9Gr0dZwJodf7MhaBE9ImwwYzeQBqfU4BcFzNlVbFRQ8ijiLzmr18Fw+y0Ce+E0vrNgy8 aAGt4DhbQd+N6/q4FZw6vOQHWcM/2Z95ZmxPY75UiEKjSwNa56R7jnqcV4lD3nVX/fg8 HFHYnJS6fpk+Mt4+vnJwIXBFt4ZmeHAEdu0g1jpKEj8hrzyeZDR7Z6Ypcc/Jh8YgYYWT qDGQ== 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=2wozZF2obWi3bpqR2T3GiMN7lQ3609teki15bRjqhCk=; b=V5D5RfIRDjPgnELJBSKbzFStuA9LRcznxHXP9+WwHu6VKUpwmp1KMKA2buxAXfwDeD ht3c/7QuSQmcftUMrBaTs0ltIJ3Yj6J4Rjb/wiUFdTWi1lOl0EuhScuGs9ewLRCNVbqf J4s1pCs+NzimW9gNd0Au2EZYOniEP3bCLx6YGDbkY9Y6UxMe0e1ZLRrJybUg0t/Jmoqm CFBBjTQEX8FkcrY9USQPilVSQu3xhDf/uDLTZt2U6aWRYU9mKSjZqhjKmyeJutVzoZX3 HbHqT7C9BRDOS1olBkb216eTpmeH5qBFPxjfyk1+AMHP925c5ILVD86v8nXo/c6vUAG6 jB1A== 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 x7-20020a170902ec8700b001874910a2c6si1921532plg.286.2022.11.10.22.11.38; Thu, 10 Nov 2022 22:11:51 -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 S231625AbiKKGKU (ORCPT <rfc822;winker.wchi@gmail.com> + 99 others); Fri, 11 Nov 2022 01:10:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43030 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229536AbiKKGKS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 11 Nov 2022 01:10:18 -0500 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D41425C4D for <linux-kernel@vger.kernel.org>; Thu, 10 Nov 2022 22:10:17 -0800 (PST) Received: from dggpemm500022.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4N7pB12sn0zbmDR; Fri, 11 Nov 2022 14:06:33 +0800 (CST) Received: from dggpemm100009.china.huawei.com (7.185.36.113) 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; Fri, 11 Nov 2022 14:10:15 +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; Fri, 11 Nov 2022 14:10:15 +0800 From: Liu Shixin <liushixin2@huawei.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J. Wysocki" <rafael@kernel.org> CC: <linux-kernel@vger.kernel.org>, Liu Shixin <liushixin2@huawei.com> Subject: [PATCH] kobject: hide illegible sysfs warning of kobject_del() Date: Fri, 11 Nov 2022 14:58:07 +0800 Message-ID: <20221111065807.3278713-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: dggems706-chm.china.huawei.com (10.3.19.183) 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?1749179026078259691?= X-GMAIL-MSGID: =?utf-8?q?1749179026078259691?= |
Series |
kobject: hide illegible sysfs warning of kobject_del()
|
|
Commit Message
Liu Shixin
Nov. 11, 2022, 6:58 a.m. UTC
Some consumers do not care whether kobject_add() succeed or failed such as
irqdesc. They call kobject_del() all the time even if kobject_add() failed.
Then kernel will report some illegible sysfs warning 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
[...]
Check whether kobject is added successfully by using kobj->state_in_sysfs
in kobject_del() and skip deleting it if not added at all.
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
---
lib/kobject.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Fri, Nov 11, 2022 at 02:58:07PM +0800, Liu Shixin wrote: > Some consumers do not care whether kobject_add() succeed or failed such as > irqdesc. They call kobject_del() all the time even if kobject_add() failed. > Then kernel will report some illegible sysfs warning 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 Why not fix the caller here? Is that somehow not possible? thanks, greg k-h
On 2022/11/11 14:26, Greg Kroah-Hartman wrote: > On Fri, Nov 11, 2022 at 02:58:07PM +0800, Liu Shixin wrote: >> Some consumers do not care whether kobject_add() succeed or failed such as >> irqdesc. They call kobject_del() all the time even if kobject_add() failed. >> Then kernel will report some illegible sysfs warning 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 > Why not fix the caller here? Is that somehow not possible? The caller should be freed by kobject_put() if kobject_add() failed. But in fact, the failure does not affect the function of the caller. So the caller do not call kobject_put() Immediately. If want to fix the caller, we can check konj->state_in_sysfs before call kobject_del(). This way has no difference with check kobj->state_in_sysfs in kobject_del(). By the way, I'm not sure how many callers have this problem. So I think it's better to fix in kobject_del(). thanks, > > thanks, > > greg k-h > . >
On Fri, Nov 11, 2022 at 04:27:03PM +0800, Liu Shixin wrote: > > > On 2022/11/11 14:26, Greg Kroah-Hartman wrote: > > On Fri, Nov 11, 2022 at 02:58:07PM +0800, Liu Shixin wrote: > >> Some consumers do not care whether kobject_add() succeed or failed such as > >> irqdesc. They call kobject_del() all the time even if kobject_add() failed. > >> Then kernel will report some illegible sysfs warning 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 > > Why not fix the caller here? Is that somehow not possible? > The caller should be freed by kobject_put() if kobject_add() failed. But in fact, the failure does not affect > the function of the caller. So the caller do not call kobject_put() Immediately. > If want to fix the caller, we can check konj->state_in_sysfs before call kobject_del(). This way has no difference > with check kobj->state_in_sysfs in kobject_del(). No, no code should ever be checking the state_in_sysfs flag before calling this function. When a kobject is done with, by the creator of it, then it can call kobject_del(). It can NOT call that function multiple times, as that is just wrong and goes against the whole way the kobject should be used. So there is something very wrong with the caller code here, THAT should be fixed. > By the way, I'm not sure how many callers have this problem. So I think it's better to fix in kobject_del(). As we have never had this report before, I don't know of many problem users. Let's fix the root of the problem here please, do not paper over it by allowing this function to be called multiple times, as that is an indication that the reference counting logic of the caller is very wrong. thanks, greg k-h
diff --git a/lib/kobject.c b/lib/kobject.c index a0b2dbfcfa23..f6163a3a41c2 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -604,7 +604,7 @@ void kobject_del(struct kobject *kobj) { struct kobject *parent; - if (!kobj) + if (!kobj || !kobj->state_in_sysfs) return; parent = kobj->parent;