Message ID | 20231009-strncpy-drivers-net-dsa-vitesse-vsc73xx-core-c-v1-1-e2427e087fad@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a888:0:b0:403:3b70:6f57 with SMTP id x8csp2161589vqo; Mon, 9 Oct 2023 15:55:03 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGhYai2Q2TKPHhMsGrvVsb3VarIBAgMtyeaTFvS/NG5rO41ZgzwXQ4i5g959IQlvqFASkKJ X-Received: by 2002:a05:6a21:1f27:b0:16e:ab42:9837 with SMTP id ry39-20020a056a211f2700b0016eab429837mr3118629pzb.29.1696892103367; Mon, 09 Oct 2023 15:55:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696892103; cv=none; d=google.com; s=arc-20160816; b=TSNU3EEPc68qZmo9q4w/Jxr0H5UeA0OUpPSbeJwWPeWoxvk4bxqmhPRKgGttTHHj0O +tAzmYnrQhLXhUNMZUlDzoWAF5m8ea0+ljtzJXD6fxoDINUSnp1xeLDcjctaoYwZlmBW IvysnB4j+tz8exdEUq6l+zUQfq8gIAyQgkwhVlQWe/44SR5hT2kmYjr2AKyDGmVvg27C /2IJY7gVnlACPqYs9zO+g50kCokYHEXunClsO/WjDgBbSWdz4/CaRFviq22Xx8jghFUl br/pndfvdwH8+zSaz2Id7bW4eRaTEjLb71NjGJpJ3e3oSaI72ay3JJpi8p5ogM98iUGb qdxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=gqq3YrEYGFNss40u9rh8HNKvaODfOxHAaOpSCan2mbI=; fh=+nR/KBYVMP75b/5EkORvVk3R3PpmbJKGYQ7gn75EMlo=; b=YG3Hd1kCT3RY5og34l6OURZ/5qk5sm7GC6XOYSeFcwPtYavmGGtD595rvzZAcDWPFt 0sWVOExMuazpPZ21p1HelwLbI6L4QteS0FA3TypXd2+b/oN3ywkzj9ctGaQ/V2qVl814 VhAa/DVMRExCDtdKzSyuRW5S+ZGduySThkxCq3tdOnxUG2frG/hS3dEE/aca9qxJEPPW X+1EYHaVDsulweg1yKHUfsOLJx+iW/NMjnBe17/j6e38semoCVxZbiB+B0YSpqz74yLn D/12xeC93ORlzjb5UxUNIef3CADyb2hLO8RjJOuE3+q5DoStAmOrbjvg1a/jPnNe3RWX Wtwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=PKj54VcP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id z8-20020a170903018800b001c9ad75c067si720695plg.149.2023.10.09.15.55.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Oct 2023 15:55:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=PKj54VcP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 9E49D81F54F2; Mon, 9 Oct 2023 15:55:00 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378947AbjJIWyo (ORCPT <rfc822;makky5685@gmail.com> + 19 others); Mon, 9 Oct 2023 18:54:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378937AbjJIWym (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 9 Oct 2023 18:54:42 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78FC6A4 for <linux-kernel@vger.kernel.org>; Mon, 9 Oct 2023 15:54:40 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-d9a581346c4so122778276.0 for <linux-kernel@vger.kernel.org>; Mon, 09 Oct 2023 15:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696892079; x=1697496879; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=gqq3YrEYGFNss40u9rh8HNKvaODfOxHAaOpSCan2mbI=; b=PKj54VcPH+Y3gu4/HHgNOJ9DfmDHm6YbJEZXlYMV3+hgRoJKbx0VkdX4ScjK8rytGf 18g5ZhBi3KwCC/QXw5THS1mlkXnODg9v6BHb8R/UvqvSgUhHh9lFu4a/y3OIvNt9S2Tj p5YrR4ZgaEODegXEILQNCVGYi/SdUGXifWhTUblPsXBZo31hOOz53YzfiXzya+f3r5rv LR0BcgQ5CPZuzHkINS0xAP4P+eun8qIpOj68kgtv4PtuRQVxAFMy1XvZ1K+YF4M25QsU 5dh4VBA3FFfJ+9y+uWgs+hiPjci+M6RcSmy0gtHWPx3BzJd5NdGBGu+TaQ8y09nY3tj6 IwCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696892079; x=1697496879; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=gqq3YrEYGFNss40u9rh8HNKvaODfOxHAaOpSCan2mbI=; b=hX6CuiWzfied7N0v54Uu2k9H9Ru/x6RcX+AKMUSbuF0zLFRmUNHfRuoidQJwF1FSXP UQjpbkVA2F9NjlFaSLGssdxDTCL0ghc3Gk4u1FuwvwgKf+gT6etJr0A/iX/Mb0vDms1X euEK50FUv1/kg7j+Fb8irjUjMBVGr8RmVw8mMJANKDr+yIaQJEz1s80KvJpzxBag6D2h yVYPoML1Z7FpI/FoXox/U9OauOJnp0abTWX9cP3KL1V8HKuDKeeWZ8HDb/KZFioZI3sd xX003EoOpYgnfgXtJonICUt4AgtwdFy5JF3Fw0OhjIzrt5fFjH7gr4griNwHf1ujHS93 U3lw== X-Gm-Message-State: AOJu0YwH/zpMU2eNH6tgghI9j0mD4EGrnIfE1Ah1GtkWKwYtXQahjfRO pyq6Zxd2ddY7sGVXwdF9vG3Rf6b5ohsv+mJmKA== X-Received: from jstitt-linux1.c.googlers.com ([fda3:e722:ac3:cc00:2b:ff92:c0a8:23b5]) (user=justinstitt job=sendgmr) by 2002:a05:6902:85:b0:d86:5644:5d12 with SMTP id h5-20020a056902008500b00d8656445d12mr302836ybs.4.1696892079757; Mon, 09 Oct 2023 15:54:39 -0700 (PDT) Date: Mon, 09 Oct 2023 22:54:37 +0000 Mime-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAK2EJGUC/x3NPQrDMAxA4asEzRXYztCfq5QOrqS0WpwgGeMQc veajt/y3gEupuLwmA4waeq6loF4mYC+uXwElYchhTTHEO7o1QptO7JpE3MsUpE9Y9Mq7oLN6Tr 3jrSaIGGkhUOmxLf4hhHdTBbt/+HzdZ4/cFU+pYAAAAA= X-Developer-Key: i=justinstitt@google.com; a=ed25519; pk=tC3hNkJQTpNX/gLKxTNQKDmiQl6QjBNCGKJINqAdJsE= X-Developer-Signature: v=1; a=ed25519-sha256; t=1696892078; l=2762; i=justinstitt@google.com; s=20230717; h=from:subject:message-id; bh=dnJs1bo1eq2tjq6VR/G42QgTFZ/5UULFEzYTX6dAjz4=; b=Gq6P/7az6Lfl/v56lJyGITjEvb9rCpFg5YZenKeB6EJWQNAyLr6rUZWZOEeJ810Sy56KUkrud LUyx/1GXlWXAjWqd+7FHFUHndSQrvYl4rzI6v7iqGR6dDD3FqnY6y7Z X-Mailer: b4 0.12.3 Message-ID: <20231009-strncpy-drivers-net-dsa-vitesse-vsc73xx-core-c-v1-1-e2427e087fad@google.com> Subject: [PATCH] net: dsa: vsc73xx: replace deprecated strncpy with ethtool_sprintf From: Justin Stitt <justinstitt@google.com> To: 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> Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, Justin Stitt <justinstitt@google.com> Content-Type: text/plain; charset="utf-8" X-Spam-Status: No, score=-4.8 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.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 (fry.vger.email [0.0.0.0]); Mon, 09 Oct 2023 15:55:00 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779320334005248524 X-GMAIL-MSGID: 1779320334005248524 |
Series |
net: dsa: vsc73xx: replace deprecated strncpy with ethtool_sprintf
|
|
Commit Message
Justin Stitt
Oct. 9, 2023, 10:54 p.m. UTC
`strncpy` is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
ethtool_sprintf() is designed specifically for get_strings() usage.
Let's replace strncpy in favor of this more robust and easier to
understand interface.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
---
Note: build-tested only.
---
drivers/net/dsa/vitesse-vsc73xx-core.c | 20 ++++++--------------
1 file changed, 6 insertions(+), 14 deletions(-)
---
base-commit: cbf3a2cb156a2c911d8f38d8247814b4c07f49a2
change-id: 20231009-strncpy-drivers-net-dsa-vitesse-vsc73xx-core-c-1cfd0ac2d81b
Best regards,
--
Justin Stitt <justinstitt@google.com>
Comments
On 10/9/23 15:54, Justin Stitt wrote: > `strncpy` is deprecated for use on NUL-terminated destination strings > [1] and as such we should prefer more robust and less ambiguous string > interfaces. > > ethtool_sprintf() is designed specifically for get_strings() usage. > Let's replace strncpy in favor of this more robust and easier to > understand interface. > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] > Link: https://github.com/KSPP/linux/issues/90 > Cc: linux-hardening@vger.kernel.org > Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
On Mon, Oct 09, 2023 at 10:54:37PM +0000, Justin Stitt wrote: > `strncpy` is deprecated for use on NUL-terminated destination strings > [1] and as such we should prefer more robust and less ambiguous string > interfaces. > > ethtool_sprintf() is designed specifically for get_strings() usage. > Let's replace strncpy in favor of this more robust and easier to > understand interface. > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] > Link: https://github.com/KSPP/linux/issues/90 > Cc: linux-hardening@vger.kernel.org > Signed-off-by: Justin Stitt <justinstitt@google.com> > --- > Note: build-tested only. > --- > drivers/net/dsa/vitesse-vsc73xx-core.c | 20 ++++++-------------- > 1 file changed, 6 insertions(+), 14 deletions(-) > > diff --git a/drivers/net/dsa/vitesse-vsc73xx-core.c b/drivers/net/dsa/vitesse-vsc73xx-core.c > index 4f09e7438f3b..09955fdea2ff 100644 > --- a/drivers/net/dsa/vitesse-vsc73xx-core.c > +++ b/drivers/net/dsa/vitesse-vsc73xx-core.c > @@ -928,7 +928,8 @@ static void vsc73xx_get_strings(struct dsa_switch *ds, int port, u32 stringset, > const struct vsc73xx_counter *cnt; > struct vsc73xx *vsc = ds->priv; > u8 indices[6]; > - int i, j; > + u8 *buf = data; > + int i; > u32 val; > int ret; > > @@ -948,10 +949,7 @@ static void vsc73xx_get_strings(struct dsa_switch *ds, int port, u32 stringset, > indices[5] = ((val >> 26) & 0x1f); /* TX counter 2 */ > > /* The first counters is the RX octets */ > - j = 0; > - strncpy(data + j * ETH_GSTRING_LEN, > - "RxEtherStatsOctets", ETH_GSTRING_LEN); > - j++; > + ethtool_sprintf(&buf, "RxEtherStatsOctets"); Here you don't use "%s", but everywhere else you do. Can't you just pass the counter name everywhere, without "%s"? > > /* Each port supports recording 3 RX counters and 3 TX counters, > * figure out what counters we use in this set-up and return the > @@ -962,22 +960,16 @@ static void vsc73xx_get_strings(struct dsa_switch *ds, int port, u32 stringset, > for (i = 0; i < 3; i++) { > cnt = vsc73xx_find_counter(vsc, indices[i], false); > if (cnt) > - strncpy(data + j * ETH_GSTRING_LEN, > - cnt->name, ETH_GSTRING_LEN); > - j++; > + ethtool_sprintf(&buf, "%s", cnt->name); The code conversion is not functionally identical, and I think it's a bit hard to make it identical. The VSC7395 has 45 port counters, but it seems that it can only monitor and display 8 of them at a time - 2 fixed and 6 configurable through some windows. vsc73xx_get_strings() detects which counter is each window configured for, based on the value of the CNT_CTRL_CFG hardware register (VSC73XX_C_CFG in the code). It displays a different string depending on the hardware value. The code must deal with the case where vsc73xx_find_counter() returns NULL, aka the hardware window is configured for a value that vsc73xx_tx_counters[] and vsc73xx_rx_counters[] don't know about. Currently, the way that this is treated is by skipping the strncpy() (and thus leaving an empty string), and incrementing j to get to the next ethtool counter, and next window. The order of the strings in vsc73xx_get_strings() needs to be strongly correlated to the order of the counters from vsc73xx_get_ethtool_stats(). So, the driver would still print counter values for the unknown windows, it will just not provide a string for them. In your proposal, the increment of j basically goes into the "if (cnt)" block because it's embedded within ethtool_sprintf(), which means that if a hardware counter is unknown, the total number of reported strings will be less than 8. Which is very problematic, because vsc73xx_get_sset_count() says that 8 strings are reported. Also, all the counter strings after the unknown one will be shifted to the left. I suggest that "if (!cnt)", you should call ethtool_sprintf() with an empty string, to preserve the original behavior. > } > > /* TX stats begins with the number of TX octets */ > - strncpy(data + j * ETH_GSTRING_LEN, > - "TxEtherStatsOctets", ETH_GSTRING_LEN); > - j++; > + ethtool_sprintf(&buf, "TxEtherStatsOctets"); > > for (i = 3; i < 6; i++) { > cnt = vsc73xx_find_counter(vsc, indices[i], true); > if (cnt) > - strncpy(data + j * ETH_GSTRING_LEN, > - cnt->name, ETH_GSTRING_LEN); > - j++; > + ethtool_sprintf(&buf, "%s", cnt->name); > } > } > > > --- > base-commit: cbf3a2cb156a2c911d8f38d8247814b4c07f49a2 > change-id: 20231009-strncpy-drivers-net-dsa-vitesse-vsc73xx-core-c-1cfd0ac2d81b > > Best regards, > -- > Justin Stitt <justinstitt@google.com> >
On Tue, Oct 10, 2023 at 4:20 AM Vladimir Oltean <olteanv@gmail.com> wrote: > > On Mon, Oct 09, 2023 at 10:54:37PM +0000, Justin Stitt wrote: > > `strncpy` is deprecated for use on NUL-terminated destination strings > > [1] and as such we should prefer more robust and less ambiguous string > > interfaces. > > > > ethtool_sprintf() is designed specifically for get_strings() usage. > > Let's replace strncpy in favor of this more robust and easier to > > understand interface. > > > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > > Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] > > Link: https://github.com/KSPP/linux/issues/90 > > Cc: linux-hardening@vger.kernel.org > > Signed-off-by: Justin Stitt <justinstitt@google.com> > > --- > > Note: build-tested only. > > --- > > drivers/net/dsa/vitesse-vsc73xx-core.c | 20 ++++++-------------- > > 1 file changed, 6 insertions(+), 14 deletions(-) > > > > diff --git a/drivers/net/dsa/vitesse-vsc73xx-core.c b/drivers/net/dsa/vitesse-vsc73xx-core.c > > index 4f09e7438f3b..09955fdea2ff 100644 > > --- a/drivers/net/dsa/vitesse-vsc73xx-core.c > > +++ b/drivers/net/dsa/vitesse-vsc73xx-core.c > > @@ -928,7 +928,8 @@ static void vsc73xx_get_strings(struct dsa_switch *ds, int port, u32 stringset, > > const struct vsc73xx_counter *cnt; > > struct vsc73xx *vsc = ds->priv; > > u8 indices[6]; > > - int i, j; > > + u8 *buf = data; > > + int i; > > u32 val; > > int ret; > > > > @@ -948,10 +949,7 @@ static void vsc73xx_get_strings(struct dsa_switch *ds, int port, u32 stringset, > > indices[5] = ((val >> 26) & 0x1f); /* TX counter 2 */ > > > > /* The first counters is the RX octets */ > > - j = 0; > > - strncpy(data + j * ETH_GSTRING_LEN, > > - "RxEtherStatsOctets", ETH_GSTRING_LEN); > > - j++; > > + ethtool_sprintf(&buf, "RxEtherStatsOctets"); > > Here you don't use "%s", but everywhere else you do. Can't you just pass > the counter name everywhere, without "%s"? > > > > > /* Each port supports recording 3 RX counters and 3 TX counters, > > * figure out what counters we use in this set-up and return the > > @@ -962,22 +960,16 @@ static void vsc73xx_get_strings(struct dsa_switch *ds, int port, u32 stringset, > > for (i = 0; i < 3; i++) { > > cnt = vsc73xx_find_counter(vsc, indices[i], false); > > if (cnt) > > - strncpy(data + j * ETH_GSTRING_LEN, > > - cnt->name, ETH_GSTRING_LEN); > > - j++; > > + ethtool_sprintf(&buf, "%s", cnt->name); > > The code conversion is not functionally identical, and I think it's a > bit hard to make it identical. > > The VSC7395 has 45 port counters, but it seems that it can only monitor > and display 8 of them at a time - 2 fixed and 6 configurable through > some windows. > > vsc73xx_get_strings() detects which counter is each window configured > for, based on the value of the CNT_CTRL_CFG hardware register (VSC73XX_C_CFG > in the code). It displays a different string depending on the hardware > value. > > The code must deal with the case where vsc73xx_find_counter() returns > NULL, aka the hardware window is configured for a value that vsc73xx_tx_counters[] > and vsc73xx_rx_counters[] don't know about. > > Currently, the way that this is treated is by skipping the strncpy() > (and thus leaving an empty string), and incrementing j to get to the > next ethtool counter, and next window. > > The order of the strings in vsc73xx_get_strings() needs to be strongly > correlated to the order of the counters from vsc73xx_get_ethtool_stats(). > So, the driver would still print counter values for the unknown windows, > it will just not provide a string for them. > > In your proposal, the increment of j basically goes into the "if (cnt)" > block because it's embedded within ethtool_sprintf(), which means that > if a hardware counter is unknown, the total number of reported strings > will be less than 8. Which is very problematic, because vsc73xx_get_sset_count() > says that 8 strings are reported. Also, all the counter strings after > the unknown one will be shifted to the left. > > I suggest that "if (!cnt)", you should call ethtool_sprintf() with an > empty string, to preserve the original behavior. Wow, thanks for the feedback here. I agree that the current proposal is problematic. I wonder what you think about using a ternary to avoid smelly code dupe: for (i = 0; i < 3; i++) { cnt = vsc73xx_find_counter(vsc, indices[i], false); ethtool_sprintf(&buf, "%s", cnt ? cnt->name : ""); } > > > } > > > > /* TX stats begins with the number of TX octets */ > > - strncpy(data + j * ETH_GSTRING_LEN, > > - "TxEtherStatsOctets", ETH_GSTRING_LEN); > > - j++; > > + ethtool_sprintf(&buf, "TxEtherStatsOctets"); > > > > for (i = 3; i < 6; i++) { > > cnt = vsc73xx_find_counter(vsc, indices[i], true); > > if (cnt) > > - strncpy(data + j * ETH_GSTRING_LEN, > > - cnt->name, ETH_GSTRING_LEN); > > - j++; > > + ethtool_sprintf(&buf, "%s", cnt->name); > > } > > } > > > > > > --- > > base-commit: cbf3a2cb156a2c911d8f38d8247814b4c07f49a2 > > change-id: 20231009-strncpy-drivers-net-dsa-vitesse-vsc73xx-core-c-1cfd0ac2d81b > > > > Best regards, > > -- > > Justin Stitt <justinstitt@google.com> > > > Thanks Justin
On Tue, Oct 10, 2023 at 4:20 AM Vladimir Oltean <olteanv@gmail.com> wrote: > > On Mon, Oct 09, 2023 at 10:54:37PM +0000, Justin Stitt wrote: > > `strncpy` is deprecated for use on NUL-terminated destination strings > > [1] and as such we should prefer more robust and less ambiguous string > > interfaces. > > > > ethtool_sprintf() is designed specifically for get_strings() usage. > > Let's replace strncpy in favor of this more robust and easier to > > understand interface. > > > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > > Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] > > Link: https://github.com/KSPP/linux/issues/90 > > Cc: linux-hardening@vger.kernel.org > > Signed-off-by: Justin Stitt <justinstitt@google.com> > > --- > > Note: build-tested only. > > --- > > drivers/net/dsa/vitesse-vsc73xx-core.c | 20 ++++++-------------- > > 1 file changed, 6 insertions(+), 14 deletions(-) > > > > diff --git a/drivers/net/dsa/vitesse-vsc73xx-core.c b/drivers/net/dsa/vitesse-vsc73xx-core.c > > index 4f09e7438f3b..09955fdea2ff 100644 > > --- a/drivers/net/dsa/vitesse-vsc73xx-core.c > > +++ b/drivers/net/dsa/vitesse-vsc73xx-core.c > > @@ -928,7 +928,8 @@ static void vsc73xx_get_strings(struct dsa_switch *ds, int port, u32 stringset, > > const struct vsc73xx_counter *cnt; > > struct vsc73xx *vsc = ds->priv; > > u8 indices[6]; > > - int i, j; > > + u8 *buf = data; > > + int i; > > u32 val; > > int ret; > > > > @@ -948,10 +949,7 @@ static void vsc73xx_get_strings(struct dsa_switch *ds, int port, u32 stringset, > > indices[5] = ((val >> 26) & 0x1f); /* TX counter 2 */ > > > > /* The first counters is the RX octets */ > > - j = 0; > > - strncpy(data + j * ETH_GSTRING_LEN, > > - "RxEtherStatsOctets", ETH_GSTRING_LEN); > > - j++; > > + ethtool_sprintf(&buf, "RxEtherStatsOctets"); > > Here you don't use "%s", but everywhere else you do. Can't you just pass > the counter name everywhere, without "%s"? Because it's a string literal, no warning there. Maybe an argument regarding style could be made. I have no style preference here so I could send v2 if you feel strongly about it. > > > > > /* Each port supports recording 3 RX counters and 3 TX counters, > > * figure out what counters we use in this set-up and return the > > @@ -962,22 +960,16 @@ static void vsc73xx_get_strings(struct dsa_switch *ds, int port, u32 stringset, > > for (i = 0; i < 3; i++) { > > cnt = vsc73xx_find_counter(vsc, indices[i], false); > > if (cnt) > > - strncpy(data + j * ETH_GSTRING_LEN, > > - cnt->name, ETH_GSTRING_LEN); > > - j++; > > + ethtool_sprintf(&buf, "%s", cnt->name); > > The code conversion is not functionally identical, and I think it's a > bit hard to make it identical. > > The VSC7395 has 45 port counters, but it seems that it can only monitor > and display 8 of them at a time - 2 fixed and 6 configurable through > some windows. > > vsc73xx_get_strings() detects which counter is each window configured > for, based on the value of the CNT_CTRL_CFG hardware register (VSC73XX_C_CFG > in the code). It displays a different string depending on the hardware > value. > > The code must deal with the case where vsc73xx_find_counter() returns > NULL, aka the hardware window is configured for a value that vsc73xx_tx_counters[] > and vsc73xx_rx_counters[] don't know about. > > Currently, the way that this is treated is by skipping the strncpy() > (and thus leaving an empty string), and incrementing j to get to the > next ethtool counter, and next window. > > The order of the strings in vsc73xx_get_strings() needs to be strongly > correlated to the order of the counters from vsc73xx_get_ethtool_stats(). > So, the driver would still print counter values for the unknown windows, > it will just not provide a string for them. > > In your proposal, the increment of j basically goes into the "if (cnt)" > block because it's embedded within ethtool_sprintf(), which means that > if a hardware counter is unknown, the total number of reported strings > will be less than 8. Which is very problematic, because vsc73xx_get_sset_count() > says that 8 strings are reported. Also, all the counter strings after > the unknown one will be shifted to the left. > > I suggest that "if (!cnt)", you should call ethtool_sprintf() with an > empty string, to preserve the original behavior. > > > } > > > > /* TX stats begins with the number of TX octets */ > > - strncpy(data + j * ETH_GSTRING_LEN, > > - "TxEtherStatsOctets", ETH_GSTRING_LEN); > > - j++; > > + ethtool_sprintf(&buf, "TxEtherStatsOctets"); > > > > for (i = 3; i < 6; i++) { > > cnt = vsc73xx_find_counter(vsc, indices[i], true); > > if (cnt) > > - strncpy(data + j * ETH_GSTRING_LEN, > > - cnt->name, ETH_GSTRING_LEN); > > - j++; > > + ethtool_sprintf(&buf, "%s", cnt->name); > > } > > } > > > > > > --- > > base-commit: cbf3a2cb156a2c911d8f38d8247814b4c07f49a2 > > change-id: 20231009-strncpy-drivers-net-dsa-vitesse-vsc73xx-core-c-1cfd0ac2d81b > > > > Best regards, > > -- > > Justin Stitt <justinstitt@google.com> > > > Thanks Justin
On Tue, Oct 10, 2023 at 02:49:26PM -0700, Justin Stitt wrote: > On Tue, Oct 10, 2023 at 4:20 AM Vladimir Oltean <olteanv@gmail.com> wrote: > > Here you don't use "%s", but everywhere else you do. Can't you just pass > > the counter name everywhere, without "%s"? > > Because it's a string literal, no warning there. Maybe an argument > regarding style could be made. I have no style preference here > so I could send v2 if you feel strongly about it. No, leave it alone here, don't add the "%s" where it's not needed. But I guess you'll have to send a v2 anyway due to the other comment.
On Tue, Oct 10, 2023 at 10:44:42AM -0700, Justin Stitt wrote: > Wow, thanks for the feedback here. I agree that the current > proposal is problematic. I wonder what you think about > using a ternary to avoid smelly code dupe: > > for (i = 0; i < 3; i++) { > cnt = vsc73xx_find_counter(vsc, indices[i], false); > ethtool_sprintf(&buf, "%s", cnt ? cnt->name : ""); > } Looks like that would address my comment, and it looks okay.
diff --git a/drivers/net/dsa/vitesse-vsc73xx-core.c b/drivers/net/dsa/vitesse-vsc73xx-core.c index 4f09e7438f3b..09955fdea2ff 100644 --- a/drivers/net/dsa/vitesse-vsc73xx-core.c +++ b/drivers/net/dsa/vitesse-vsc73xx-core.c @@ -928,7 +928,8 @@ static void vsc73xx_get_strings(struct dsa_switch *ds, int port, u32 stringset, const struct vsc73xx_counter *cnt; struct vsc73xx *vsc = ds->priv; u8 indices[6]; - int i, j; + u8 *buf = data; + int i; u32 val; int ret; @@ -948,10 +949,7 @@ static void vsc73xx_get_strings(struct dsa_switch *ds, int port, u32 stringset, indices[5] = ((val >> 26) & 0x1f); /* TX counter 2 */ /* The first counters is the RX octets */ - j = 0; - strncpy(data + j * ETH_GSTRING_LEN, - "RxEtherStatsOctets", ETH_GSTRING_LEN); - j++; + ethtool_sprintf(&buf, "RxEtherStatsOctets"); /* Each port supports recording 3 RX counters and 3 TX counters, * figure out what counters we use in this set-up and return the @@ -962,22 +960,16 @@ static void vsc73xx_get_strings(struct dsa_switch *ds, int port, u32 stringset, for (i = 0; i < 3; i++) { cnt = vsc73xx_find_counter(vsc, indices[i], false); if (cnt) - strncpy(data + j * ETH_GSTRING_LEN, - cnt->name, ETH_GSTRING_LEN); - j++; + ethtool_sprintf(&buf, "%s", cnt->name); } /* TX stats begins with the number of TX octets */ - strncpy(data + j * ETH_GSTRING_LEN, - "TxEtherStatsOctets", ETH_GSTRING_LEN); - j++; + ethtool_sprintf(&buf, "TxEtherStatsOctets"); for (i = 3; i < 6; i++) { cnt = vsc73xx_find_counter(vsc, indices[i], true); if (cnt) - strncpy(data + j * ETH_GSTRING_LEN, - cnt->name, ETH_GSTRING_LEN); - j++; + ethtool_sprintf(&buf, "%s", cnt->name); } }