`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: [email protected]
Signed-off-by: Justin Stitt <[email protected]>
---
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");
/* 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);
}
}
---
base-commit: cbf3a2cb156a2c911d8f38d8247814b4c07f49a2
change-id: 20231009-strncpy-drivers-net-dsa-vitesse-vsc73xx-core-c-1cfd0ac2d81b
Best regards,
--
Justin Stitt <[email protected]>
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: [email protected]
> Signed-off-by: Justin Stitt <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
--
Florian
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: [email protected]
> Signed-off-by: Justin Stitt <[email protected]>
> ---
> 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 <[email protected]>
>
On Tue, Oct 10, 2023 at 4:20 AM Vladimir Oltean <[email protected]> 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: [email protected]
> > Signed-off-by: Justin Stitt <[email protected]>
> > ---
> > 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 <[email protected]>
> >
>
Thanks
Justin
On Tue, Oct 10, 2023 at 4:20 AM Vladimir Oltean <[email protected]> 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: [email protected]
> > Signed-off-by: Justin Stitt <[email protected]>
> > ---
> > 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 <[email protected]>
> >
>
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 <[email protected]> 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.