Message ID | 20231206071655.1626479-1-sean@geanix.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp3934335vqy; Tue, 5 Dec 2023 23:17:51 -0800 (PST) X-Google-Smtp-Source: AGHT+IHhuJflqxsSdTLW+5wz5B+Hoak2zoyniPTNfuToWZbjNX9/PSbr9MO+zjvCiCZnOqML4y9I X-Received: by 2002:a05:6870:501:b0:1fb:75b:2ba5 with SMTP id j1-20020a056870050100b001fb075b2ba5mr285221oao.97.1701847070784; Tue, 05 Dec 2023 23:17:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701847070; cv=none; d=google.com; s=arc-20160816; b=AU4SUwOm+RWCwvAQ1iNgagI6nzRmC8xnv90QQ89/Sx2uH7KwH8VzeCEgdyZkSthVyS XbyRpsLGXlMFOkzIfulnHUnZuawyKp39rvDM5zpU0Xb9qIhPGDk+gN746qFE2V4/y9U7 SurPkPq1X3x06DssAVURSGwXr87xEWpa4UMBhQYRhcbBF4AnC8IKxkklw/3Rj2+ivcHb U0qYxe733mi9HDOt2G1Ew7OkWOQsdhjlpluSvbZJ6t40+fWvNjrEEtBUP0aWVuSfcyNv Mj8aUZnMJsuY00pvYMVA6sFFKGH13ALiftTjjE4JutQW/zftci587IjGZP/wtZuHUZHX tbNA== 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:dkim-signature; bh=+H62xYUVYv9m4br7cg0DgyNn6m4JbUs5+N/PVPX56JM=; fh=uKvpeuvk3JF9LfD67BE/M+DIhAvDvegRMd/dnAqLNyk=; b=oTlKBltvA4dj659ujbegYIH9vwGKf0RbGT/OS19SxzKaE3Ujg8A02zMvpFz1qQgp3B gGLnHFD5ZYIV3EhvBRwKPK1yLWoXL9QrrRGfXNG8w4KDv0kHN0P2hYcSOV0/UI6nTPyU ol6txe6rDX9ZHwoxpra/B80JiRMaIyua7aJuZ7IzN0GRthknvSel9AH/aUWHlOyWxtjk yfVnVKMRus6ISgmb2D5fqmR/lFyKsyPmR8DFb28BCdPNGOyeAo9y3NJFXf51xFmFxptp FXoI/Rd2HGkZZLVEgWvFEESCSxrG0dlKqRjvJcOh4VExlapFJvhvV6JjZp7YsJpSbh8O nTSQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@geanix.com header.s=default2211 header.b="orh0/fxn"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=geanix.com Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id f23-20020a63f117000000b0059779ae5899si10942123pgi.836.2023.12.05.23.17.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 23:17:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@geanix.com header.s=default2211 header.b="orh0/fxn"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=geanix.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 45662803F7AE; Tue, 5 Dec 2023 23:17:46 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376962AbjLFHRh (ORCPT <rfc822;pusanteemu@gmail.com> + 99 others); Wed, 6 Dec 2023 02:17:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376923AbjLFHRg (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 6 Dec 2023 02:17:36 -0500 Received: from www530.your-server.de (www530.your-server.de [188.40.30.78]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC65F135; Tue, 5 Dec 2023 23:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=geanix.com; s=default2211; h=Content-Transfer-Encoding:MIME-Version:Message-ID:Date: Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References; bh=+H62xYUVYv9m4br7cg0DgyNn6m4JbUs5+N/PVPX56JM=; b=orh0/fxnE4NeMLDDyd/Te3IbWW 3OIDv19m9XNBLLmL0BneUzz1K1wcODjswD+O8g1TI5nfiL8G74Ecn0qqfJ1aAlb6CA9YsmdrocFF0 SV2GiVg/oC5O5vpiNs2ySi8VsBrEcyCPbQ3OO75FMiCtek4cCNvPyyg5wo0uGtER7HKLoH1BjRL/H v5zul/3wD5U4Umggmj+8L7EugVxamtCHJyUdpKWu+SVBzEZieqhRr24jcB0eVq/6rfmjvn/bWWgbN IOYobp8jH3LXpOmqZJaAisFBLHExOV8LLv8Vf7lWKW3nX0rYk1P14FuoiQWbCOLxMtNc6CjuIpXw6 LXdH5vGw==; Received: from sslproxy05.your-server.de ([78.46.172.2]) by www530.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <sean@geanix.com>) id 1rAmA7-0009kh-21; Wed, 06 Dec 2023 08:17:39 +0100 Received: from [185.17.218.86] (helo=zen..) by sslproxy05.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <sean@geanix.com>) id 1rAmA6-000Kzf-CG; Wed, 06 Dec 2023 08:17:38 +0100 From: Sean Nyekjaer <sean@geanix.com> To: Woojung Huh <woojung.huh@microchip.com>, UNGLinuxDriver@microchip.com, Andrew Lunn <andrew@lunn.ch>, Florian Fainelli <f.fainelli@gmail.com>, Vladimir Oltean <olteanv@gmail.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Arun Ramadoss <arun.ramadoss@microchip.com>, Christian Eggers <ceggers@arri.de> Cc: Sean Nyekjaer <sean@geanix.com>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 net] net: dsa: microchip: provide a list of valid protocols for xmit handler Date: Wed, 6 Dec 2023 08:16:54 +0100 Message-ID: <20231206071655.1626479-1-sean@geanix.com> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Authenticated-Sender: sean@geanix.com X-Virus-Scanned: Clear (ClamAV 0.103.10/27114/Tue Dec 5 09:39:00 2023) X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 05 Dec 2023 23:17:46 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784515994052881090 X-GMAIL-MSGID: 1784515994052881090 |
Series |
[v2,net] net: dsa: microchip: provide a list of valid protocols for xmit handler
|
|
Commit Message
Sean Nyekjaer
Dec. 6, 2023, 7:16 a.m. UTC
Provide a list of valid protocols for which the driver will provide
it's deferred xmit handler.
When using DSA_TAG_PROTO_KSZ8795 protocol, it does not provide a
"connect" method, therefor ksz_connect() is not allocating ksz_tagger_data.
This avoids the following null pointer dereference:
ksz_connect_tag_protocol from dsa_register_switch+0x9ac/0xee0
dsa_register_switch from ksz_switch_register+0x65c/0x828
ksz_switch_register from ksz_spi_probe+0x11c/0x168
ksz_spi_probe from spi_probe+0x84/0xa8
spi_probe from really_probe+0xc8/0x2d8
Fixes: ab32f56a4100 ("net: dsa: microchip: ptp: add packet transmission timestamping")
Signed-off-by: Sean Nyekjaer <sean@geanix.com>
---
https://lore.kernel.org/netdev/20231205124636.1345761-1-sean@geanix.com/#R
Changes since v1:
- Provided a list of valid protocols
drivers/net/dsa/microchip/ksz_common.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
Comments
Hi Sean, > -----Original Message----- > From: Sean Nyekjaer <sean@geanix.com> > Sent: Wednesday, December 6, 2023 12:47 PM > To: Woojung Huh - C21699 <Woojung.Huh@microchip.com>; > UNGLinuxDriver <UNGLinuxDriver@microchip.com>; Andrew Lunn > <andrew@lunn.ch>; Florian Fainelli <f.fainelli@gmail.com>; Vladimir Oltean > <olteanv@gmail.com>; David S. Miller <davem@davemloft.net>; Eric Dumazet > <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni > <pabeni@redhat.com>; Arun Ramadoss - I17769 > <Arun.Ramadoss@microchip.com>; Christian Eggers <ceggers@arri.de> > Cc: Sean Nyekjaer <sean@geanix.com>; netdev@vger.kernel.org; linux- > kernel@vger.kernel.org > Subject: [PATCH v2 net] net: dsa: microchip: provide a list of valid protocols for > xmit handler > > [Some people who received this message don't often get email from > sean@geanix.com. Learn why this is important at > https://aka.ms/LearnAboutSenderIdentification ] > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Provide a list of valid protocols for which the driver will provide it's deferred > xmit handler. > > When using DSA_TAG_PROTO_KSZ8795 protocol, it does not provide a > "connect" method, therefor ksz_connect() is not allocating ksz_tagger_data. > > This avoids the following null pointer dereference: > ksz_connect_tag_protocol from dsa_register_switch+0x9ac/0xee0 > dsa_register_switch from ksz_switch_register+0x65c/0x828 > ksz_switch_register from ksz_spi_probe+0x11c/0x168 ksz_spi_probe from > spi_probe+0x84/0xa8 spi_probe from really_probe+0xc8/0x2d8 > > Fixes: ab32f56a4100 ("net: dsa: microchip: ptp: add packet transmission > timestamping") > Signed-off-by: Sean Nyekjaer <sean@geanix.com> > --- > https://lore.kernel.org/netdev/20231205124636.1345761-1- > sean@geanix.com/#R > Changes since v1: > - Provided a list of valid protocols > > drivers/net/dsa/microchip/ksz_common.c | 16 ++++++++++++---- > 1 file changed, 12 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/dsa/microchip/ksz_common.c > b/drivers/net/dsa/microchip/ksz_common.c > index 42db7679c360..286e20f340e5 100644 > --- a/drivers/net/dsa/microchip/ksz_common.c > +++ b/drivers/net/dsa/microchip/ksz_common.c > @@ -2624,10 +2624,18 @@ static int ksz_connect_tag_protocol(struct > dsa_switch *ds, { > struct ksz_tagger_data *tagger_data; > > - tagger_data = ksz_tagger_data(ds); > - tagger_data->xmit_work_fn = ksz_port_deferred_xmit; > - > - return 0; > + switch (proto) { > + case DSA_TAG_PROTO_KSZ8795: > + return 0; > + case DSA_TAG_PROTO_KSZ9893: > + case DSA_TAG_PROTO_KSZ9477: > + case DSA_TAG_PROTO_LAN937X: > + tagger_data = ksz_tagger_data(ds); > + tagger_data->xmit_work_fn = ksz_port_deferred_xmit; NULL check is missing here. > + return 0; > + default: > + return -EPROTONOSUPPORT; > + } > } > > static int ksz_port_vlan_filtering(struct dsa_switch *ds, int port, > -- > 2.42.0
On Wed, Dec 06, 2023 at 05:22:55PM +0000, Madhuri.Sripada@microchip.com wrote:
> NULL check is missing here.
Don't just leave it there, also explain why.
Hi Vladimir and Madhuri, > On 6 Dec 2023, at 18.35, Vladimir Oltean <olteanv@gmail.com> wrote: > > On Wed, Dec 06, 2023 at 05:22:55PM +0000, Madhuri.Sripada@microchip.com wrote: >> NULL check is missing here. Did here what every other driver does, that uses the connect_tag_protocol() method. (As per Vladimir’s instructions) Not one of them, does a NULL check. > > Don't just leave it there, also explain why. Message to me? /Sean
On Wed, Dec 06, 2023 at 06:45:12PM +0100, Sean Nyekjaer wrote: > > Don't just leave it there, also explain why. > > Message to me? > > /Sean No, to Madhuri (as the To: field suggests). In the Linux kernel it's not a good practice to put defensive checks which don't have a logical justification, because other people end up not knowing why they're there, and when they can be removed. Checking for the tagging protocol gives a very clear indication and traceability of why it is being done, on the other hand. If the ds->tagger_data is NULL for a tagging protocol for which it was expected it shouldn't be, and the DSA core still decides to call ds->ops->connect_tag_protocol() anyway, this is a violation of the API contract established with all drivers that use this mechanism. Papering over a bug in the DSA core results in silent failures, which means that any further behavior is unpredictable. So I'd very much prefer the system to fail fast in case of a bug in the framework, so that it can be reported and fixed. With rigorous testing, it will fail earlier than in the production stage. I only said "don't leave it there, also explain why" because I really don't appreciate review comments spreading FUD, for which I'd have to spend 20-30 minutes to explain why leaving out the NULL pointer checking is, in fact, safe. Of course, I am not excluding a not-yet-found bug either, but I am strongly encouraging Madhuri to walk through the code path and point it to us, and strongly discouraging lazy review comments. It's not fair for me to reply to a 5 word sentence with a wall of text. So I replied with a phrase of comparable length to the suggestion.
On Wed, Dec 06, 2023 at 08:16:54AM +0100, Sean Nyekjaer wrote: > Provide a list of valid protocols for which the driver will provide > it's deferred xmit handler. > > When using DSA_TAG_PROTO_KSZ8795 protocol, it does not provide a > "connect" method, therefor ksz_connect() is not allocating ksz_tagger_data. > > This avoids the following null pointer dereference: > ksz_connect_tag_protocol from dsa_register_switch+0x9ac/0xee0 > dsa_register_switch from ksz_switch_register+0x65c/0x828 > ksz_switch_register from ksz_spi_probe+0x11c/0x168 > ksz_spi_probe from spi_probe+0x84/0xa8 > spi_probe from really_probe+0xc8/0x2d8 > > Fixes: ab32f56a4100 ("net: dsa: microchip: ptp: add packet transmission timestamping") > Signed-off-by: Sean Nyekjaer <sean@geanix.com> > --- Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
On 12/5/23 23:16, Sean Nyekjaer wrote: > Provide a list of valid protocols for which the driver will provide > it's deferred xmit handler. > > When using DSA_TAG_PROTO_KSZ8795 protocol, it does not provide a > "connect" method, therefor ksz_connect() is not allocating ksz_tagger_data. > > This avoids the following null pointer dereference: > ksz_connect_tag_protocol from dsa_register_switch+0x9ac/0xee0 > dsa_register_switch from ksz_switch_register+0x65c/0x828 > ksz_switch_register from ksz_spi_probe+0x11c/0x168 > ksz_spi_probe from spi_probe+0x84/0xa8 > spi_probe from really_probe+0xc8/0x2d8 > > Fixes: ab32f56a4100 ("net: dsa: microchip: ptp: add packet transmission timestamping") > Signed-off-by: Sean Nyekjaer <sean@geanix.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Vlad, > -----Original Message----- > From: Vladimir Oltean <olteanv@gmail.com> > Sent: Wednesday, December 6, 2023 11:32 PM > To: Sean Nyekjaer <sean@geanix.com> > Cc: Madhuri Sripada - I34878 <Madhuri.Sripada@microchip.com>; Woojung > Huh - C21699 <Woojung.Huh@microchip.com>; UNGLinuxDriver > <UNGLinuxDriver@microchip.com>; andrew@lunn.ch; f.fainelli@gmail.com; > davem@davemloft.net; edumazet@google.com; kuba@kernel.org; > pabeni@redhat.com; Arun Ramadoss - I17769 > <Arun.Ramadoss@microchip.com>; ceggers@arri.de; > netdev@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v2 net] net: dsa: microchip: provide a list of valid > protocols for xmit handler > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Wed, Dec 06, 2023 at 06:45:12PM +0100, Sean Nyekjaer wrote: > > > Don't just leave it there, also explain why. > > > > Message to me? > > > > /Sean > > No, to Madhuri (as the To: field suggests). > > In the Linux kernel it's not a good practice to put defensive checks which don't > have a logical justification, because other people end up not knowing why > they're there, and when they can be removed. Checking for the tagging > protocol gives a very clear indication and traceability of why it is being done, > on the other hand. > > If the ds->tagger_data is NULL for a tagging protocol for which it was expected > it shouldn't be, and the DSA core still decides to call > ds->ops->connect_tag_protocol() anyway, this is a violation of the API > contract established with all drivers that use this mechanism. Papering over a > bug in the DSA core results in silent failures, which means that any further > behavior is unpredictable. So I'd very much prefer the system to fail fast in case > of a bug in the framework, so that it can be reported and fixed. With rigorous > testing, it will fail earlier than in the production stage. > > I only said "don't leave it there, also explain why" because I really don't > appreciate review comments spreading FUD, for which I'd have to spend 20- > 30 minutes to explain why leaving out the NULL pointer checking is, in fact, > safe. > > Of course, I am not excluding a not-yet-found bug either, but I am strongly > encouraging Madhuri to walk through the code path and point it to us, and > strongly discouraging lazy review comments. It's not fair for me to reply to a 5 > word sentence with a wall of text. So I replied with a phrase of comparable > length to the suggestion. I am new in this community and reviews. And was reviewing from code point of view where NULL check is a primary requirement and a general practice. I understand the justification and will make a note of it in my further reviews and my kernel development as well. Thanks for your inputs. -Madhuri
Hello: This patch was applied to bpf/bpf.git (master) by Jakub Kicinski <kuba@kernel.org>: On Wed, 6 Dec 2023 08:16:54 +0100 you wrote: > Provide a list of valid protocols for which the driver will provide > it's deferred xmit handler. > > When using DSA_TAG_PROTO_KSZ8795 protocol, it does not provide a > "connect" method, therefor ksz_connect() is not allocating ksz_tagger_data. > > This avoids the following null pointer dereference: > ksz_connect_tag_protocol from dsa_register_switch+0x9ac/0xee0 > dsa_register_switch from ksz_switch_register+0x65c/0x828 > ksz_switch_register from ksz_spi_probe+0x11c/0x168 > ksz_spi_probe from spi_probe+0x84/0xa8 > spi_probe from really_probe+0xc8/0x2d8 > > [...] Here is the summary with links: - [v2,net] net: dsa: microchip: provide a list of valid protocols for xmit handler https://git.kernel.org/bpf/bpf/c/1499b89289bf You are awesome, thank you!
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c index 42db7679c360..286e20f340e5 100644 --- a/drivers/net/dsa/microchip/ksz_common.c +++ b/drivers/net/dsa/microchip/ksz_common.c @@ -2624,10 +2624,18 @@ static int ksz_connect_tag_protocol(struct dsa_switch *ds, { struct ksz_tagger_data *tagger_data; - tagger_data = ksz_tagger_data(ds); - tagger_data->xmit_work_fn = ksz_port_deferred_xmit; - - return 0; + switch (proto) { + case DSA_TAG_PROTO_KSZ8795: + return 0; + case DSA_TAG_PROTO_KSZ9893: + case DSA_TAG_PROTO_KSZ9477: + case DSA_TAG_PROTO_LAN937X: + tagger_data = ksz_tagger_data(ds); + tagger_data->xmit_work_fn = ksz_port_deferred_xmit; + return 0; + default: + return -EPROTONOSUPPORT; + } } static int ksz_port_vlan_filtering(struct dsa_switch *ds, int port,