linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net-next] hinic: avoid gcc -Wrestrict warning
@ 2021-03-23 12:56 Arnd Bergmann
  2021-03-23 21:40 ` Rasmus Villemoes
  0 siblings, 1 reply; 2+ messages in thread
From: Arnd Bergmann @ 2021-03-23 12:56 UTC (permalink / raw)
  To: Bin Luo, David S. Miller, Jakub Kicinski
  Cc: Arnd Bergmann, netdev, linux-kernel

From: Arnd Bergmann <arnd@arndb.de>

With extra warnings enabled, gcc complains that snprintf should not
take the same buffer as source and destination:

drivers/net/ethernet/huawei/hinic/hinic_ethtool.c: In function 'hinic_set_settings_to_hw':
drivers/net/ethernet/huawei/hinic/hinic_ethtool.c:480:9: error: 'snprintf' argument 4 overlaps destination object 'set_link_str' [-Werror=restrict]
  480 |   err = snprintf(set_link_str, SET_LINK_STR_MAX_LEN,
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  481 |           "%sspeed %d ", set_link_str, speed);
      |           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_ethtool.c:464:7: note: destination object referenced by 'restrict'-qualified argument 1 was declared here
  464 |  char set_link_str[SET_LINK_STR_MAX_LEN] = {0};

Rewrite this to remember the offset of the previous printf output
instead.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/ethernet/huawei/hinic/hinic_ethtool.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
index c340d9acba80..74aefc8fc4d8 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
@@ -464,7 +464,7 @@ static int hinic_set_settings_to_hw(struct hinic_dev *nic_dev,
 	char set_link_str[SET_LINK_STR_MAX_LEN] = {0};
 	struct net_device *netdev = nic_dev->netdev;
 	enum nic_speed_level speed_level = 0;
-	int err;
+	int err, off;
 
 	err = snprintf(set_link_str, SET_LINK_STR_MAX_LEN, "%s",
 		       (set_settings & HILINK_LINK_SET_AUTONEG) ?
@@ -475,10 +475,11 @@ static int hinic_set_settings_to_hw(struct hinic_dev *nic_dev,
 		return -EFAULT;
 	}
 
+	off = err;
 	if (set_settings & HILINK_LINK_SET_SPEED) {
 		speed_level = hinic_ethtool_to_hw_speed_level(speed);
-		err = snprintf(set_link_str, SET_LINK_STR_MAX_LEN,
-			       "%sspeed %d ", set_link_str, speed);
+		err = snprintf(set_link_str + off, SET_LINK_STR_MAX_LEN - off,
+			       "speed %d ", speed);
 		if (err <= 0 || err >= SET_LINK_STR_MAX_LEN) {
 			netif_err(nic_dev, drv, netdev, "Failed to snprintf link speed, function return(%d) and dest_len(%d)\n",
 				  err, SET_LINK_STR_MAX_LEN);
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH net-next] hinic: avoid gcc -Wrestrict warning
  2021-03-23 12:56 [PATCH net-next] hinic: avoid gcc -Wrestrict warning Arnd Bergmann
@ 2021-03-23 21:40 ` Rasmus Villemoes
  0 siblings, 0 replies; 2+ messages in thread
From: Rasmus Villemoes @ 2021-03-23 21:40 UTC (permalink / raw)
  To: Arnd Bergmann, Bin Luo, David S. Miller, Jakub Kicinski
  Cc: Arnd Bergmann, netdev, linux-kernel

On 23/03/2021 13.56, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> With extra warnings enabled, gcc complains that snprintf should not
> take the same buffer as source and destination:
> 
> drivers/net/ethernet/huawei/hinic/hinic_ethtool.c: In function 'hinic_set_settings_to_hw':
> drivers/net/ethernet/huawei/hinic/hinic_ethtool.c:480:9: error: 'snprintf' argument 4 overlaps destination object 'set_link_str' [-Werror=restrict]
>   480 |   err = snprintf(set_link_str, SET_LINK_STR_MAX_LEN,
>       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   481 |           "%sspeed %d ", set_link_str, speed);
>       |           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/ethernet/huawei/hinic/hinic_ethtool.c:464:7: note: destination object referenced by 'restrict'-qualified argument 1 was declared here
>   464 |  char set_link_str[SET_LINK_STR_MAX_LEN] = {0};
> 
> Rewrite this to remember the offset of the previous printf output
> instead.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/net/ethernet/huawei/hinic/hinic_ethtool.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
> index c340d9acba80..74aefc8fc4d8 100644
> --- a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
> @@ -464,7 +464,7 @@ static int hinic_set_settings_to_hw(struct hinic_dev *nic_dev,
>  	char set_link_str[SET_LINK_STR_MAX_LEN] = {0};
>  	struct net_device *netdev = nic_dev->netdev;
>  	enum nic_speed_level speed_level = 0;
> -	int err;
> +	int err, off;
>  
>  	err = snprintf(set_link_str, SET_LINK_STR_MAX_LEN, "%s",
>  		       (set_settings & HILINK_LINK_SET_AUTONEG) ?
> @@ -475,10 +475,11 @@ static int hinic_set_settings_to_hw(struct hinic_dev *nic_dev,
>  		return -EFAULT;
>  	}
>  
> +	off = err;
>  	if (set_settings & HILINK_LINK_SET_SPEED) {
>  		speed_level = hinic_ethtool_to_hw_speed_level(speed);
> -		err = snprintf(set_link_str, SET_LINK_STR_MAX_LEN,
> -			       "%sspeed %d ", set_link_str, speed);
> +		err = snprintf(set_link_str + off, SET_LINK_STR_MAX_LEN - off,
> +			       "speed %d ", speed);
>  		if (err <= 0 || err >= SET_LINK_STR_MAX_LEN) {

This is broken, the second snprintf has no longer overflown if "err >=
SET_LINK_STR_MAX_LEN", but if "err >= SET_LINK_STR_MAX_LEN - off". (The
existing err <= 0 check is also bogus, but that's a different story).

But, I think these conversions where you use snprintf are all broken,
it's only a matter of time before gcc or another static analyzer also
learns a
"Wusing-return-value-from-snprintf-as-index-to-output-buffer-is-fragile-because,you-know,snprintf-semantics..."
and then we'd have to revisit all these. You should in general, when
building a string by repeatedly printf'ing to a local buffer, use the
"len += scnprintf()" pattern. That doesn't easily provide a "have we
overflown at some point" so is not directly applicable here, but all the
more reason to start making use of seq_buf to wrap a local char buffer
in a nice abstraction that lets you seq_buf_printf() and ask
seq_buf_has_overflowed().

Rasmus

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-03-23 21:42 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-23 12:56 [PATCH net-next] hinic: avoid gcc -Wrestrict warning Arnd Bergmann
2021-03-23 21:40 ` Rasmus Villemoes

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).