Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp127106pxu; Wed, 2 Dec 2020 17:06:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJwRe0oTCzmrtwA0NG2ufzqZ2Mmr8+MpBFYZjQ1ytOfNec6+NpGlAVy+4clfXqj3JGzRYABQ X-Received: by 2002:a17:906:24c3:: with SMTP id f3mr437436ejb.238.1606957607450; Wed, 02 Dec 2020 17:06:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606957607; cv=none; d=google.com; s=arc-20160816; b=CEAKSf+mp4CCdP7G4G7g5RstR4TjNA8kcVfG05TiyQTWDN5Q1h9Fj6fBR6PkvLtMIL t9l1Esq/hEYJKwOsF8/cLX1mx1T3gdVv/NQlKp27XjsMWjKJiUucIdnJs/ms+3vjYCAw IQwyBJe1Lyy0HixpQvK9tNlznwWeDtSdmV+XDbSUVGqy0VE9tovyBzVBEbzBOLfHeUb9 XVQc7Wv5upkxA12V/t85SbbDZMUUIR21+F7hX4lwuENLSqywdReHUCiLrIVQKdJmXLJc E9xHoj+HOhbAtKS3N08C8oAeXNNpgmr9j4zE8bd4MJZ/kI7e0d8CCtes+D6tdh4HMCRz Ee5A== 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 :references:in-reply-to:message-id:subject:cc:to:from:dkim-signature :date; bh=Fex3aR8vnEGNKGeS/FC0h6GncX9YZO6Kb5c9KGucvwM=; b=u9x/LcAV6W6zphuvYJ0nUmfWKRkcjmCWUVuHHRs6C/7iXfAnX9Qt3T1XcCphb03UJS eimmIJUopYkjhF7R3hU0zjcURqsTiJSwNQ0dFp2S4MZCv8oz65A8zcwFTflcrHXXwt8g Tsn24gWoZhtgrhk6/7UjUvk7iTOLBcothX0SIBNegf+U6//52/KODYQX99eBKQhRJG6Z s7jDU5UfkM741B7ANO7uM1J+SGrw6lLhbGNM5Hlu80Ai/DLKs6S+JPqpEtpIufL5akTt jS0VkO5PDadhhmbK1Mu+aAAZ7IU5Q2zikdLtyKFXd5tSokfTJPzbxIUVttXAVXrnoSK7 t8ww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ZBnOAi9m; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p10si171381eji.254.2020.12.02.17.06.08; Wed, 02 Dec 2020 17:06:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ZBnOAi9m; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727153AbgLCBEm (ORCPT + 99 others); Wed, 2 Dec 2020 20:04:42 -0500 Received: from mail.kernel.org ([198.145.29.99]:59446 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726851AbgLCBEl (ORCPT ); Wed, 2 Dec 2020 20:04:41 -0500 Date: Wed, 2 Dec 2020 17:03:59 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1606957440; bh=e27nxQB6v2bR4jfkrSYiga7jg2DKJygkFb9Kd8AZ4A8=; h=From:To:Cc:Subject:In-Reply-To:References:From; b=ZBnOAi9moSb5Q48aM5+oabBxGmMJk1G6PX/ufjfMOskIVpIF7i7XT6c6ZVFfc9IM+ /DhBdmUOnwVWskBIbnP+UMgOimZ7VchF6mgvTlZ8W0l8CfvdiBkpB/m/3dQhLv82KJ w2GNUw0On5aoTaoP+0KrnwLE0+cyrBmejs6jbnt5QVLqMNGevgfoujRuv7H+O7euBz MTyFGy8PL1RIc5FQMaf3ghHmHDvFT+7BUSEKbvKi6vsY+NA4f7mB2aEdZlArGZfTsl uw4c8mVvmT05e0CYutlnGtZIwsfEsJ+q7RfYrEWrgTKBPlKmdcUnNqa0jBuSCE4Ae2 Q5z+lF3Ph5RSg== From: Jakub Kicinski To: Wang Hai Cc: , , , , , Subject: Re: [PATCH net] net: bridge: Fix a warning when del bridge sysfs Message-ID: <20201202170359.19330bda@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com> In-Reply-To: <20201201140114.67455-1-wanghai38@huawei.com> References: <20201201140114.67455-1-wanghai38@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 1 Dec 2020 22:01:14 +0800 Wang Hai wrote: > If adding bridge sysfs fails, br->ifobj will be NULL, there is no > need to delete its non-existent sysfs when deleting the bridge device, > otherwise, it will cause a warning. So, when br->ifobj == NULL, > directly return can fix this bug. > > br_sysfs_addbr: can't create group bridge4/bridge > ------------[ cut here ]------------ > sysfs group 'bridge' not found for kobject 'bridge4' > WARNING: CPU: 2 PID: 9004 at fs/sysfs/group.c:279 sysfs_remove_group fs/sysfs/group.c:279 [inline] > WARNING: CPU: 2 PID: 9004 at fs/sysfs/group.c:279 sysfs_remove_group+0x153/0x1b0 fs/sysfs/group.c:270 > Modules linked in: iptable_nat > ... > Call Trace: > br_dev_delete+0x112/0x190 net/bridge/br_if.c:384 > br_dev_newlink net/bridge/br_netlink.c:1381 [inline] > br_dev_newlink+0xdb/0x100 net/bridge/br_netlink.c:1362 > __rtnl_newlink+0xe11/0x13f0 net/core/rtnetlink.c:3441 > rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3500 > rtnetlink_rcv_msg+0x385/0x980 net/core/rtnetlink.c:5562 > netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2494 > netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] > netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1330 > netlink_sendmsg+0x793/0xc80 net/netlink/af_netlink.c:1919 > sock_sendmsg_nosec net/socket.c:651 [inline] > sock_sendmsg+0x139/0x170 net/socket.c:671 > ____sys_sendmsg+0x658/0x7d0 net/socket.c:2353 > ___sys_sendmsg+0xf8/0x170 net/socket.c:2407 > __sys_sendmsg+0xd3/0x190 net/socket.c:2440 > do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > Reported-by: Hulk Robot > Signed-off-by: Wang Hai Nik, is this the way you want to handle this? Should the notifier not fail if sysfs files cannot be created? Currently br_sysfs_addbr() returns an int but the only caller ignores it. > diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c > index 7db06e3f642a..1e9cbf31d904 100644 > --- a/net/bridge/br_sysfs_br.c > +++ b/net/bridge/br_sysfs_br.c > @@ -991,6 +991,9 @@ void br_sysfs_delbr(struct net_device *dev) > struct kobject *kobj = &dev->dev.kobj; > struct net_bridge *br = netdev_priv(dev); > > + if (!br->ifobj) > + return; > + > kobject_put(br->ifobj); > sysfs_remove_bin_file(kobj, &bridge_forward); > sysfs_remove_group(kobj, &bridge_group);