All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH net-next 0/2] net: fix variable shadowing spam from headers
@ 2024-03-29 16:59 Alexander Lobakin
  2024-03-29 16:59 ` [PATCH net-next 1/2] net/tcp: fix -Wshadow / Sparse shadow warnings in tcp_hash_fail() Alexander Lobakin
  2024-03-29 17:00 ` [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse shadow warnings throughout the file Alexander Lobakin
  0 siblings, 2 replies; 11+ messages in thread
From: Alexander Lobakin @ 2024-03-29 16:59 UTC (permalink / raw
  To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
  Cc: Alexander Lobakin, Dmitry Safonov, Heiner Kallweit,
	nex.sw.ncis.osdt.itp.upstreaming, netdev, linux-kernel

W=12 and/or C=1 are useful to test new code, but warnings coming from
the generic headers are noisy and distract a lot.
Fix the two most noisy networking header files by using __UNIQUE_ID()
for the variables declared inside macros. The rest seems to be clean,
except for the recent Clang's enum-conversion (which's sanity is still
under discussion).

Alexander Lobakin (2):
  net/tcp: fix -Wshadow / Sparse shadow warnings in tcp_hash_fail()
  netdev_queues: fix -Wshadow / Sparse shadow warnings throughout the
    file

 include/net/netdev_queues.h | 54 +++++++++++++++++++++++++++----------
 include/net/tcp_ao.h        |  6 ++++-
 2 files changed, 45 insertions(+), 15 deletions(-)

-- 
2.44.0


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

* [PATCH net-next 1/2] net/tcp: fix -Wshadow / Sparse shadow warnings in tcp_hash_fail()
  2024-03-29 16:59 [PATCH net-next 0/2] net: fix variable shadowing spam from headers Alexander Lobakin
@ 2024-03-29 16:59 ` Alexander Lobakin
  2024-03-29 17:00 ` [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse shadow warnings throughout the file Alexander Lobakin
  1 sibling, 0 replies; 11+ messages in thread
From: Alexander Lobakin @ 2024-03-29 16:59 UTC (permalink / raw
  To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
  Cc: Alexander Lobakin, Dmitry Safonov, Heiner Kallweit,
	nex.sw.ncis.osdt.itp.upstreaming, netdev, linux-kernel

Fix the following spam coming from <net/tcp_ao.h> when building with
W=12 and/or C=1:

Clang:

In file included from drivers/net/ethernet/intel/idpf/idpf_txrx.c:4:
In file included from drivers/net/ethernet/intel/idpf/idpf.h:24:
In file included from drivers/net/ethernet/intel/idpf/idpf_txrx.h:8:
./include/net/tcp.h:2812:3: warning: declaration shadows a local variable [-Wshadow]
 2812 |                 tcp_hash_fail("TCP segment has incorrect auth options set",
      |                 ^
./include/net/tcp_ao.h:153:23: note: expanded from macro 'tcp_hash_fail'
  153 |         const struct tcphdr *th = tcp_hdr(skb);                         \
      |                              ^
./include/net/tcp.h:2805:23: note: previous declaration is here
 2805 |         const struct tcphdr *th = tcp_hdr(skb);
      |                              ^
./include/net/tcp.h:2820:4: warning: declaration shadows a local variable [-Wshadow]
 2820 |                         tcp_hash_fail("TCP connection can't start/end using TCP-AO",
      |                         ^
./include/net/tcp_ao.h:153:23: note: expanded from macro 'tcp_hash_fail'
  153 |         const struct tcphdr *th = tcp_hdr(skb);                         \
      |                              ^
./include/net/tcp.h:2805:23: note: previous declaration is here
 2805 |         const struct tcphdr *th = tcp_hdr(skb);
      |                              ^
./include/net/tcp.h:2840:4: warning: declaration shadows a local variable [-Wshadow]
 2840 |                         tcp_hash_fail("AO hash is required, but not found",
      |                         ^
./include/net/tcp_ao.h:153:23: note: expanded from macro 'tcp_hash_fail'
  153 |         const struct tcphdr *th = tcp_hdr(skb);                         \
      |                              ^
./include/net/tcp.h:2805:23: note: previous declaration is here
 2805 |         const struct tcphdr *th = tcp_hdr(skb);
      |                              ^
./include/net/tcp.h:2846:4: warning: declaration shadows a local variable [-Wshadow]

Sparse:

drivers/net/ethernet/intel/idpf/idpf_main.c: note: in included file (through drivers/net/ethernet/intel/idpf/idpf_txrx.h, drivers/net/ethernet/intel/idpf/idpf.h):
./include/net/tcp.h:2812:17: warning: symbol 'th' shadows an earlier one
./include/net/tcp.h:2805:29: originally declared here
./include/net/tcp.h:2820:25: warning: symbol 'th' shadows an earlier one
./include/net/tcp.h:2805:29: originally declared here
./include/net/tcp.h:2840:25: warning: symbol 'th' shadows an earlier one
./include/net/tcp.h:2805:29: originally declared here
./include/net/tcp.h:2846:25: warning: symbol 'th' shadows an earlier one
./include/net/tcp.h:2805:29: originally declared here

Just use __UNIQUE_ID() for the variables declared inside
tcp_hash_fail().

Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
---
 include/net/tcp_ao.h | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/net/tcp_ao.h b/include/net/tcp_ao.h
index 471e177362b4..c5303c9c6f80 100644
--- a/include/net/tcp_ao.h
+++ b/include/net/tcp_ao.h
@@ -148,7 +148,7 @@ static inline bool tcp_hash_should_produce_warnings(void)
 	return static_branch_tcp_md5() || static_branch_tcp_ao();
 }
 
-#define tcp_hash_fail(msg, family, skb, fmt, ...)			\
+#define _tcp_hash_fail(msg, family, skb, th, hdr_flags, f, fmt, ...)	\
 do {									\
 	const struct tcphdr *th = tcp_hdr(skb);				\
 	char hdr_flags[6];						\
@@ -179,6 +179,10 @@ do {									\
 				hdr_flags, ##__VA_ARGS__);		\
 	}								\
 } while (0)
+#define tcp_hash_fail(msg, family, skb, fmt, ...)			\
+	_tcp_hash_fail(msg, family, skb, __UNIQUE_ID(th_),		\
+		       __UNIQUE_ID(hdr_flags_), __UNIQUE_ID(f_), fmt,	\
+		       ##__VA_ARGS__)
 
 #ifdef CONFIG_TCP_AO
 /* TCP-AO structures and functions */
-- 
2.44.0


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

* [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse shadow warnings throughout the file
  2024-03-29 16:59 [PATCH net-next 0/2] net: fix variable shadowing spam from headers Alexander Lobakin
  2024-03-29 16:59 ` [PATCH net-next 1/2] net/tcp: fix -Wshadow / Sparse shadow warnings in tcp_hash_fail() Alexander Lobakin
@ 2024-03-29 17:00 ` Alexander Lobakin
  2024-03-29 20:18     ` Jakub Kicinski
  1 sibling, 1 reply; 11+ messages in thread
From: Alexander Lobakin @ 2024-03-29 17:00 UTC (permalink / raw
  To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
  Cc: Alexander Lobakin, Dmitry Safonov, Heiner Kallweit,
	nex.sw.ncis.osdt.itp.upstreaming, netdev, linux-kernel

Fix the following spam coming from <net/netdev_queues.h> when building
with W=12 and/or C=1:

Clang:

drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:9: warning: declaration shadows a local variable [-Wshadow]
 1992 |         return netif_txq_maybe_stop(nq, IDPF_DESC_UNUSED(tx_q), size, size);
      |                ^
./include/net/netdev_queues.h:137:11: note: expanded from macro 'netif_txq_maybe_stop'
  137 |                         _res = netif_txq_try_stop(txq, get_desc, start_thrs); \
      |                                ^
./include/net/netdev_queues.h:92:7: note: expanded from macro 'netif_txq_try_stop'
   92 |                 int _res;                                               \
      |                     ^
drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:9: note: previous declaration is here
./include/net/netdev_queues.h:133:7: note: expanded from macro 'netif_txq_maybe_stop'
  133 |                 int _res;                                               \
      |                     ^

Sparse:

drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: warning: symbol '_res' shadows an earlier one
drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: originally declared here

Use __UNIQUE_ID() in all of the macros which declare local variables.

Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
---
 include/net/netdev_queues.h | 54 +++++++++++++++++++++++++++----------
 1 file changed, 40 insertions(+), 14 deletions(-)

diff --git a/include/net/netdev_queues.h b/include/net/netdev_queues.h
index 1ec408585373..317d6bfe32c7 100644
--- a/include/net/netdev_queues.h
+++ b/include/net/netdev_queues.h
@@ -87,14 +87,14 @@ struct netdev_stat_ops {
  * be updated before invoking the macros.
  */
 
-#define netif_txq_try_stop(txq, get_desc, start_thrs)			\
+#define _netif_txq_try_stop(txq, get_desc, start_thrs, _res)		\
 	({								\
 		int _res;						\
 									\
 		netif_tx_stop_queue(txq);				\
 		/* Producer index and stop bit must be visible		\
 		 * to consumer before we recheck.			\
-		 * Pairs with a barrier in __netif_txq_completed_wake(). \
+		 * Pairs with a barrier in ___netif_txq_completed_wake(). \
 		 */							\
 		smp_mb__after_atomic();					\
 									\
@@ -107,16 +107,20 @@ struct netdev_stat_ops {
 			_res = -1;					\
 		}							\
 		_res;							\
-	})								\
+	})
+#define netif_txq_try_stop(txq, get_desc, start_thrs)			\
+	_netif_txq_try_stop(txq, get_desc, start_thrs,			\
+			    __UNIQUE_ID(res_))
 
 /**
- * netif_txq_maybe_stop() - locklessly stop a Tx queue, if needed
+ * _netif_txq_maybe_stop() - locklessly stop a Tx queue, if needed
  * @txq:	struct netdev_queue to stop/start
  * @get_desc:	get current number of free descriptors (see requirements below!)
  * @stop_thrs:	minimal number of available descriptors for queue to be left
  *		enabled
  * @start_thrs:	minimal number of descriptors to re-enable the queue, can be
  *		equal to @stop_thrs or higher to avoid frequent waking
+ * @_res: __UNIQUE_ID() to avoid variable name clash
  *
  * All arguments may be evaluated multiple times, beware of side effects.
  * @get_desc must be a formula or a function call, it must always
@@ -128,7 +132,8 @@ struct netdev_stat_ops {
  *	 1 if the queue was left enabled
  *	-1 if the queue was re-enabled (raced with waking)
  */
-#define netif_txq_maybe_stop(txq, get_desc, stop_thrs, start_thrs)	\
+#define _netif_txq_maybe_stop(txq, get_desc, stop_thrs, start_thrs,	\
+			      _res)					\
 	({								\
 		int _res;						\
 									\
@@ -136,7 +141,10 @@ struct netdev_stat_ops {
 		if (unlikely(get_desc < stop_thrs))			\
 			_res = netif_txq_try_stop(txq, get_desc, start_thrs); \
 		_res;							\
-	})								\
+	})
+#define netif_txq_maybe_stop(txq, get_desc, stop_thrs, start_thrs)	\
+	_netif_txq_maybe_stop(txq, get_desc, stop_thrs, start_thrs,	\
+			      __UNIQUE_ID(res_))
 
 /* Variant of netdev_tx_completed_queue() which guarantees smp_mb() if
  * @bytes != 0, regardless of kernel config.
@@ -152,7 +160,7 @@ netdev_txq_completed_mb(struct netdev_queue *dev_queue,
 }
 
 /**
- * __netif_txq_completed_wake() - locklessly wake a Tx queue, if needed
+ * ___netif_txq_completed_wake() - locklessly wake a Tx queue, if needed
  * @txq:	struct netdev_queue to stop/start
  * @pkts:	number of packets completed
  * @bytes:	number of bytes completed
@@ -160,6 +168,7 @@ netdev_txq_completed_mb(struct netdev_queue *dev_queue,
  * @start_thrs:	minimal number of descriptors to re-enable the queue
  * @down_cond:	down condition, predicate indicating that the queue should
  *		not be woken up even if descriptors are available
+ * @_res: __UNIQUE_ID() to avoid variable name clash
  *
  * All arguments may be evaluated multiple times.
  * @get_desc must be a formula or a function call, it must always
@@ -171,15 +180,15 @@ netdev_txq_completed_mb(struct netdev_queue *dev_queue,
  *	 1 if the queue was already enabled (or disabled but @down_cond is true)
  *	-1 if the queue was left unchanged (@start_thrs not reached)
  */
-#define __netif_txq_completed_wake(txq, pkts, bytes,			\
-				   get_desc, start_thrs, down_cond)	\
+#define ___netif_txq_completed_wake(txq, pkts, bytes, get_desc,		\
+				    start_thrs, down_cond, _res)	\
 	({								\
 		int _res;						\
 									\
 		/* Report to BQL and piggy back on its barrier.		\
 		 * Barrier makes sure that anybody stopping the queue	\
 		 * after this point sees the new consumer index.	\
-		 * Pairs with barrier in netif_txq_try_stop().		\
+		 * Pairs with barrier in _netif_txq_try_stop().		\
 		 */							\
 		netdev_txq_completed_mb(txq, pkts, bytes);		\
 									\
@@ -194,30 +203,43 @@ netdev_txq_completed_mb(struct netdev_queue *dev_queue,
 		}							\
 		_res;							\
 	})
+#define __netif_txq_completed_wake(txq, pkts, bytes, get_desc,		\
+				   start_thrs, down_cond)		\
+	___netif_txq_completed_wake(txq, pkts, bytes, get_desc,		\
+				    start_thrs, down_cond,		\
+				    __UNIQUE_ID(res_))
 
 #define netif_txq_completed_wake(txq, pkts, bytes, get_desc, start_thrs) \
 	__netif_txq_completed_wake(txq, pkts, bytes, get_desc, start_thrs, false)
 
 /* subqueue variants follow */
 
-#define netif_subqueue_try_stop(dev, idx, get_desc, start_thrs)		\
+#define _netif_subqueue_try_stop(dev, idx, get_desc, start_thrs, txq)	\
 	({								\
 		struct netdev_queue *txq;				\
 									\
 		txq = netdev_get_tx_queue(dev, idx);			\
 		netif_txq_try_stop(txq, get_desc, start_thrs);		\
 	})
+#define netif_subqueue_try_stop(dev, idx, get_desc, start_thrs)		\
+	_netif_subqueue_try_stop(dev, idx, get_desc, start_thrs,	\
+				 __UNIQUE_ID(txq_))
 
-#define netif_subqueue_maybe_stop(dev, idx, get_desc, stop_thrs, start_thrs) \
+#define _netif_subqueue_maybe_stop(dev, idx, get_desc, stop_thrs,	\
+				   start_thrs, txq)			\
 	({								\
 		struct netdev_queue *txq;				\
 									\
 		txq = netdev_get_tx_queue(dev, idx);			\
 		netif_txq_maybe_stop(txq, get_desc, stop_thrs, start_thrs); \
 	})
+#define netif_subqueue_maybe_stop(dev, idx, get_desc, stop_thrs,	\
+				  start_thrs)				\
+	_netif_subqueue_maybe_stop(dev, idx, get_desc, stop_thrs,	\
+				   start_thrs, __UNIQUE_ID(txq_))
 
-#define netif_subqueue_completed_wake(dev, idx, pkts, bytes,		\
-				      get_desc, start_thrs)		\
+#define _netif_subqueue_completed_wake(dev, idx, pkts, bytes, get_desc,	\
+				       start_thrs, txq)			\
 	({								\
 		struct netdev_queue *txq;				\
 									\
@@ -225,5 +247,9 @@ netdev_txq_completed_mb(struct netdev_queue *dev_queue,
 		netif_txq_completed_wake(txq, pkts, bytes,		\
 					 get_desc, start_thrs);		\
 	})
+#define netif_subqueue_completed_wake(dev, idx, pkts, bytes, get_desc,	\
+				      start_thrs)			\
+	_netif_subqueue_completed_wake(dev, idx, pkts, bytes, get_desc,	\
+				       start_thrs, __UNIQUE_ID(txq_))
 
 #endif
-- 
2.44.0


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

* Re: [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse shadow warnings throughout the file
@ 2024-03-29 20:18     ` Jakub Kicinski
  0 siblings, 0 replies; 11+ messages in thread
From: Jakub Kicinski @ 2024-03-29 20:18 UTC (permalink / raw
  To: Alexander Lobakin
  Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Dmitry Safonov,
	Heiner Kallweit, nex.sw.ncis.osdt.itp.upstreaming, netdev,
	linux-kernel

On Fri, 29 Mar 2024 18:00:00 +0100 Alexander Lobakin wrote:
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:9: warning: declaration shadows a local variable [-Wshadow]
>  1992 |         return netif_txq_maybe_stop(nq, IDPF_DESC_UNUSED(tx_q), size, size);
>       |                ^
> ./include/net/netdev_queues.h:137:11: note: expanded from macro 'netif_txq_maybe_stop'
>   137 |                         _res = netif_txq_try_stop(txq, get_desc, start_thrs); \
>       |                                ^
> ./include/net/netdev_queues.h:92:7: note: expanded from macro 'netif_txq_try_stop'
>    92 |                 int _res;                                               \
>       |                     ^
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:9: note: previous declaration is here
> ./include/net/netdev_queues.h:133:7: note: expanded from macro 'netif_txq_maybe_stop'
>   133 |                 int _res;                                               \
>       |                     ^
> 
> Sparse:
> 
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: warning: symbol '_res' shadows an earlier one
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: originally declared here

I don't see these building with LLVM=1 W=12 C=1
and I really don't like complicating the code because the compiler
is stupid. Can't you solve this with some renames? Add another
underscore or something?

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

* Re: [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse shadow warnings throughout the file
@ 2024-03-29 20:18     ` Jakub Kicinski
  0 siblings, 0 replies; 11+ messages in thread
From: Jakub Kicinski @ 2024-03-29 20:18 UTC (permalink / raw
  To: Alexander Lobakin
  Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Dmitry Safonov,
	Heiner Kallweit, nex.sw.ncis.osdt.itp.upstreaming, netdev,
	linux-kernel

On Fri, 29 Mar 2024 18:00:00 +0100 Alexander Lobakin wrote:
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:9: warning: declaration shadows a local variable [-Wshadow]
>  1992 |         return netif_txq_maybe_stop(nq, IDPF_DESC_UNUSED(tx_q), size, size);
>       |                ^
> ./include/net/netdev_queues.h:137:11: note: expanded from macro 'netif_txq_maybe_stop'
>   137 |                         _res = netif_txq_try_stop(txq, get_desc, start_thrs); \
>       |                                ^
> ./include/net/netdev_queues.h:92:7: note: expanded from macro 'netif_txq_try_stop'
>    92 |                 int _res;                                               \
>       |                     ^
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:9: note: previous declaration is here
> ./include/net/netdev_queues.h:133:7: note: expanded from macro 'netif_txq_maybe_stop'
>   133 |                 int _res;                                               \
>       |                     ^
> 
> Sparse:
> 
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: warning: symbol '_res' shadows an earlier one
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: originally declared here

I don't see these building with LLVM=1 W=12 C=1
and I really don't like complicating the code because the compiler
is stupid. Can't you solve this with some renames? Add another
underscore or something?

X-sender: <netdev+bounces-83456-steffen.klassert=secunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=rfc822;steffen.klassert@secunet.com NOTIFY=NEVER; X-ExtendedProps=BQAVABYAAgAAAAUAFAARAPDFCS25BAlDktII2g02frgPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAGIAAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249U3RlZmZlbiBLbGFzc2VydDY4YwUACwAXAL4AAACheZxkHSGBRqAcAp3ukbifQ049REI2LENOPURhdGFiYXNlcyxDTj1FeGNoYW5nZSBBZG1pbmlzdHJhdGl2ZSBHcm91cCAoRllESUJPSEYyM1NQRExUKSxDTj1BZG1pbmlzdHJhdGl2ZSBHcm91cHMsQ049c2VjdW5ldCxDTj1NaWNyb3NvZnQgRXhjaGFuZ2UsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1zZWN1bmV0LERDPWRlBQAOABEABiAS9uuMOkqzwmEZDvWNNQUAHQAPAAwAAABtYngtZXNzZW4tMDIFADwAAgAADwA2AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50LkRpc3BsYXlOYW1lDwARAAAAS2xhc3NlcnQsIFN0ZWZmZW4FAAwAAgAABQBsAAIAAAUAWAAXAEoAAADwxQktuQQJQ5LSCNoNNn64Q049S2xhc3NlcnQgU3RlZmZlbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ==
X-CreatedBy: MSExchange15
X-HeloDomain: b.mx.secunet.com
X-ExtendedProps: BQBjAAoAdEWmlidQ3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAAQAFCABAAAAHAAAAHN0ZWZmZW4ua2xhc3NlcnRAc2VjdW5ldC5jb20FAAYAAgABBQApAAIAAQ8ACQAAAENJQXVkaXRlZAIAAQUAAgAHAAEAAAAFAAMABwAAAAAABQAFAAIAAQUAYgAKAD8AAADLigAABQBkAA8AAwAAAEh1Yg==
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 62.96.220.37
X-EndOfInjectedXHeaders: 10852
Received: from cas-essen-01.secunet.de (10.53.40.201) by
 mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.37; Fri, 29 Mar 2024 21:19:11 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-01.secunet.de
 (10.53.40.201) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
 Transport; Fri, 29 Mar 2024 21:19:11 +0100
Received: from localhost (localhost [127.0.0.1])
	by b.mx.secunet.com (Postfix) with ESMTP id 231DC202E4
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 21:19:11 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=2.1
	tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.099, DKIM_SIGNED=0.1,
	DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MAILING_LIST_MULTI=-1,
	RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
	autolearn=ham autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
	dkim=pass (2048-bit key) header.d=kernel.org
Received: from b.mx.secunet.com ([127.0.0.1])
	by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id aF1NBVBoN0ru for <steffen.klassert@secunet.com>;
	Fri, 29 Mar 2024 21:19:10 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.75.80.249; helo=am.mirrors.kernel.org; envelope-from=netdev+bounces-83456-steffen.klassert=secunet.com@vger.kernel.org; receiver=steffen.klassert@secunet.com 
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com 82B0520270
Authentication-Results: b.mx.secunet.com;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mmn7bK5p"
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by b.mx.secunet.com (Postfix) with ESMTPS id 82B0520270
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 21:19:10 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by am.mirrors.kernel.org (Postfix) with ESMTPS id 37E431F22E43
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 20:19:10 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 62E3C13BC31;
	Fri, 29 Mar 2024 20:19:04 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mmn7bK5p"
X-Original-To: netdev@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 850C532C89;
	Fri, 29 Mar 2024 20:18:59 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1711743539; cv=none; b=qkg7bZWXnaWDqWm9OMTUKldCzr+aNi+EkgMvCd0cCOINFWNv90wOE+ERbfY0DBPTauBHBaZ9F5mNf6Oxz3hsUD/Wnqcq1irchTYluVZNbYEQfBfNjMl3RXI06FFyQURD+G7Ueun+7E3NgP0JwLeziiZASuexXNS0dP6vHnpObQI=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1711743539; c=relaxed/simple;
	bh=XtVImmmSugd7Y+fhFyNSmTR6NDHudXo4Ksas1gA4z/s=;
	h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=Qqu4zCBTiJqgGnFdGLm/XtOGp4Us/lbdid0E7apFgBNq55apYx3ut6lCEtpoylX8bJ46arI5BqiniTPLcyz6+ZXWHLs3DnCqKNHsi8EkPv89ErnAleQGgT47rA5XApiBVz9a6chCtJtPcLnjFZbwyX4bGxsfvhhj1nWKqcr171M=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mmn7bK5p; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57D45C433C7;
	Fri, 29 Mar 2024 20:18:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1711743538;
	bh=XtVImmmSugd7Y+fhFyNSmTR6NDHudXo4Ksas1gA4z/s=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=mmn7bK5praEFKZSEsXD1U0+/BhIiMgbRjlqzURm8mJyxcKdG1u7nFhvjWn6vjh45L
	 4fMwTQz5BgPAhQhwxhdzDjswpLr9tfxyAozEWodJ9d27CxJ4UL4UFY8Hf3KdPpUow8
	 E8A+MEP24fcOZoxGi8rhDy8xtbiVoeUdXbHP4PlO33ntnqxcbRNqN9U47LzjpdNssC
	 YPsQGwM2m4yyhH+9eEUxcjM4Ffzgd6RloWxtSrDibmFc5c1SFjvFY0/UkKocjbZRfB
	 tH6Rp6GsCq/VsJXLXe3LZL+Iv2yl9gsZmI2qe8RWHTL8tXGuYUE5J+9mVzpCC1gcYY
	 0Sa+AbTpHn+oA==
Date: Fri, 29 Mar 2024 13:18:57 -0700
From: Jakub Kicinski <kuba@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>, Eric Dumazet
 <edumazet@google.com>, Paolo Abeni <pabeni@redhat.com>, Dmitry Safonov
 <0x7f454c46@gmail.com>, Heiner Kallweit <hkallweit1@gmail.com>,
 nex.sw.ncis.osdt.itp.upstreaming@intel.com, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse
 shadow warnings throughout the file
Message-ID: <20240329131857.730c6528@kernel.org>
In-Reply-To: <20240329170000.3241460-3-aleksander.lobakin@intel.com>
References: <20240329170000.3241460-1-aleksander.lobakin@intel.com>
	<20240329170000.3241460-3-aleksander.lobakin@intel.com>
Precedence: bulk
X-Mailing-List: netdev@vger.kernel.org
List-Id: <netdev.vger.kernel.org>
List-Subscribe: <mailto:netdev+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:netdev+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Return-Path: netdev+bounces-83456-steffen.klassert=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 29 Mar 2024 20:19:11.1805
 (UTC)
X-MS-Exchange-Organization-Network-Message-Id: ac983536-0487-46b2-3f43-08dc502d7edb
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.201
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-01.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=mbx-essen-02.secunet.de:TOTAL-HUB=0.188|SMR=0.134(SMRDE=0.005|SMRC=0.129(SMRCL=0.102|X-SMRCR=0.128))|CAT=0.053(CATRESL=0.022
 (CATRESLP2R=0.001)|CATORES=0.028(CATRS=0.027(CATRS-Index Routing
 Agent=0.025)));2024-03-29T20:19:11.388Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-01.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 7867
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRV=cas-essen-01.secunet.de:TOTAL-FE=0.020|SMR=0.008(SMRPI=0.006(SMRPI-FrontendProxyAgent=0.006))|SMS=0.012
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-essen-02
X-MS-Exchange-Organization-RulesExecuted: mbx-essen-02
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAWYDAAAPAAADH4sIAAAAAAAEAL1UUW/bRgymZEu25Xgtin
 av45sTLEsip2gbBVlRJC0QIG0HBF0xrK1wltj4UFnn3EmOPexX7BeP
 J9lLm2SLkYcd5IN8JL+PH8nTX923Ob7SchMHe/haaBzsDB5j+Cza2e
 EHf9wJeX+R0UzkKWk8UUPxReZ4oVVBUS/4GVMtp6TNdk7FNhUj0vZF
 5gVl2zKdfK62uJjp2VYShXt7g2gvwguhc5mfRZhSkgktCqlyNCORqg
 uDAjOViAynQksxzAh//+l9bfto+dCC4J+4XJqKUufIrNLynMdjMR9S
 bAo1Wc/PN/H46JdX8dHL08P43Zt3py+P1otZfL6xiUb+QfW+sV/hVu
 sSd7E+WdsWC0qyMqVKJf9SmsbnJZVktkZRuPs0CsMIc1sSpNnElirF
 z1qNcSwSrbB/U3b9mpWjr7P+s2JNBg++Ulfoea2N/2ziGRVxSiZhIY
 XQRVyMtNnYxw//IegOArlpT1eUt0xvIQ6/adVy8XRUwvZvy+3KulXW
 p7sOZK1tomkqVWm+GUtpkDFolTHYXblMN0zB7v9dKOtzOhHaVPf4Tp
 ULn3x1l818PFQZ9m3C/cvbnCMJnUn+dqic7syitDyTuciy+aI5XNq6
 Lb3gGFOV9ws0RMh4hnBYyizlpPBCFiM8Ofn19UGI7w/CAR4ehL2AO4
 PH/OGo4arYTH4hTNR4ksmE+86hjMQHKYNRIkpDi4PxRGakewGPhSnK
 iUy38FBYhLkq0ahsah3ZWDEbNSbmycWYzHN8kaZcDmUl94LSfk5Noj
 SxtsqRw/Kz51YQgAuNBniuA11+7Huz6XhtgLbT8QA88DsQtKDtVTtb
 28DnfhO8pgMd3sFzHLcJwFEOgAONFnS6sMbODrjs2YZuy+lZB7jnQ4
 udHoLPODWIa+ngfoXDVk6jCQ3emta6XjP6DvSgxVYmagCbm65N2/pw
 MhzoXYF1utYNfmiAz+cPqnOrCzxWyujtKpZNgWWJrrNYfKdRy7nCco
 nmrFVpPLKY8NuKxanRuD6ufQ/+TeCN1NcEfl9Rf/Dhu1vZ64pxa3zo
 cBT7u7ZTHNVaMTaAbpXMoq11JnV6S3XuonSswHFrCezG57bvFfga9O
 pGLEkDdvbtdF2ORP20bJ42YeZln87fEYsguz0IAAABDs8BUmV0cmll
 dmVyT3BlcmF0b3IsMTAsMDtSZXRyaWV2ZXJPcGVyYXRvciwxMSwxO1
 Bvc3REb2NQYXJzZXJPcGVyYXRvciwxMCwwO1Bvc3REb2NQYXJzZXJP
 cGVyYXRvciwxMSwwO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcG
 VyYXRvciwxMCwxO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcGVy
 YXRvciwxMSwwO1RyYW5zcG9ydFdyaXRlclByb2R1Y2VyLDIwLDE1
X-MS-Exchange-Forest-IndexAgent: 1 1092
X-MS-Exchange-Forest-EmailMessageHash: 7E5A4F6D
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent

On Fri, 29 Mar 2024 18:00:00 +0100 Alexander Lobakin wrote:
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:9: warning: declaration shadows a local variable [-Wshadow]
>  1992 |         return netif_txq_maybe_stop(nq, IDPF_DESC_UNUSED(tx_q), size, size);
>       |                ^
> ./include/net/netdev_queues.h:137:11: note: expanded from macro 'netif_txq_maybe_stop'
>   137 |                         _res = netif_txq_try_stop(txq, get_desc, start_thrs); \
>       |                                ^
> ./include/net/netdev_queues.h:92:7: note: expanded from macro 'netif_txq_try_stop'
>    92 |                 int _res;                                               \
>       |                     ^
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:9: note: previous declaration is here
> ./include/net/netdev_queues.h:133:7: note: expanded from macro 'netif_txq_maybe_stop'
>   133 |                 int _res;                                               \
>       |                     ^
> 
> Sparse:
> 
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: warning: symbol '_res' shadows an earlier one
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: originally declared here

I don't see these building with LLVM=1 W=12 C=1
and I really don't like complicating the code because the compiler
is stupid. Can't you solve this with some renames? Add another
underscore or something?

X-sender: <linux-kernel+bounces-125384-steffen.klassert=secunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=rfc822;steffen.klassert@secunet.com NOTIFY=NEVER; X-ExtendedProps=BQAVABYAAgAAAAUAFAARAPDFCS25BAlDktII2g02frgPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAGIAAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249U3RlZmZlbiBLbGFzc2VydDY4YwUACwAXAL4AAACheZxkHSGBRqAcAp3ukbifQ049REI2LENOPURhdGFiYXNlcyxDTj1FeGNoYW5nZSBBZG1pbmlzdHJhdGl2ZSBHcm91cCAoRllESUJPSEYyM1NQRExUKSxDTj1BZG1pbmlzdHJhdGl2ZSBHcm91cHMsQ049c2VjdW5ldCxDTj1NaWNyb3NvZnQgRXhjaGFuZ2UsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1zZWN1bmV0LERDPWRlBQAOABEABiAS9uuMOkqzwmEZDvWNNQUAHQAPAAwAAABtYngtZXNzZW4tMDIFADwAAgAADwA2AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50LkRpc3BsYXlOYW1lDwARAAAAS2xhc3NlcnQsIFN0ZWZmZW4FAAwAAgAABQBsAAIAAAUAWAAXAEoAAADwxQktuQQJQ5LSCNoNNn64Q049S2xhc3NlcnQgU3RlZmZlbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ==
X-CreatedBy: MSExchange15
X-HeloDomain: b.mx.secunet.com
X-ExtendedProps: BQBjAAoAdEWmlidQ3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAAQAFCABAAAAHAAAAHN0ZWZmZW4ua2xhc3NlcnRAc2VjdW5ldC5jb20FAAYAAgABBQApAAIAAQ8ACQAAAENJQXVkaXRlZAIAAQUAAgAHAAEAAAAFAAMABwAAAAAABQAFAAIAAQUAYgAKAEAAAADLigAABQBkAA8AAwAAAEh1Yg==
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 62.96.220.37
X-EndOfInjectedXHeaders: 10906
Received: from cas-essen-01.secunet.de (10.53.40.201) by
 mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.37; Fri, 29 Mar 2024 21:19:25 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-01.secunet.de
 (10.53.40.201) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
 Transport; Fri, 29 Mar 2024 21:19:25 +0100
Received: from localhost (localhost [127.0.0.1])
	by b.mx.secunet.com (Postfix) with ESMTP id D198D20315
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 21:19:25 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=2.1
	tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.099, DKIM_SIGNED=0.1,
	DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MAILING_LIST_MULTI=-1,
	RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
	autolearn=unavailable autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
	dkim=pass (2048-bit key) header.d=kernel.org
Received: from b.mx.secunet.com ([127.0.0.1])
	by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 04wgTj6sZHGR for <steffen.klassert@secunet.com>;
	Fri, 29 Mar 2024 21:19:25 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=139.178.88.99; helo=sv.mirrors.kernel.org; envelope-from=linux-kernel+bounces-125384-steffen.klassert=secunet.com@vger.kernel.org; receiver=steffen.klassert@secunet.com 
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com 0140A202E4
Authentication-Results: b.mx.secunet.com;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mmn7bK5p"
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by b.mx.secunet.com (Postfix) with ESMTPS id 0140A202E4
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 21:19:24 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by sv.mirrors.kernel.org (Postfix) with ESMTPS id 11885287903
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 20:19:23 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id A657D13BAFC;
	Fri, 29 Mar 2024 20:19:08 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mmn7bK5p"
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 850C532C89;
	Fri, 29 Mar 2024 20:18:59 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1711743539; cv=none; b=qkg7bZWXnaWDqWm9OMTUKldCzr+aNi+EkgMvCd0cCOINFWNv90wOE+ERbfY0DBPTauBHBaZ9F5mNf6Oxz3hsUD/Wnqcq1irchTYluVZNbYEQfBfNjMl3RXI06FFyQURD+G7Ueun+7E3NgP0JwLeziiZASuexXNS0dP6vHnpObQI=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1711743539; c=relaxed/simple;
	bh=XtVImmmSugd7Y+fhFyNSmTR6NDHudXo4Ksas1gA4z/s=;
	h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=Qqu4zCBTiJqgGnFdGLm/XtOGp4Us/lbdid0E7apFgBNq55apYx3ut6lCEtpoylX8bJ46arI5BqiniTPLcyz6+ZXWHLs3DnCqKNHsi8EkPv89ErnAleQGgT47rA5XApiBVz9a6chCtJtPcLnjFZbwyX4bGxsfvhhj1nWKqcr171M=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mmn7bK5p; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57D45C433C7;
	Fri, 29 Mar 2024 20:18:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1711743538;
	bh=XtVImmmSugd7Y+fhFyNSmTR6NDHudXo4Ksas1gA4z/s=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=mmn7bK5praEFKZSEsXD1U0+/BhIiMgbRjlqzURm8mJyxcKdG1u7nFhvjWn6vjh45L
	 4fMwTQz5BgPAhQhwxhdzDjswpLr9tfxyAozEWodJ9d27CxJ4UL4UFY8Hf3KdPpUow8
	 E8A+MEP24fcOZoxGi8rhDy8xtbiVoeUdXbHP4PlO33ntnqxcbRNqN9U47LzjpdNssC
	 YPsQGwM2m4yyhH+9eEUxcjM4Ffzgd6RloWxtSrDibmFc5c1SFjvFY0/UkKocjbZRfB
	 tH6Rp6GsCq/VsJXLXe3LZL+Iv2yl9gsZmI2qe8RWHTL8tXGuYUE5J+9mVzpCC1gcYY
	 0Sa+AbTpHn+oA==
Date: Fri, 29 Mar 2024 13:18:57 -0700
From: Jakub Kicinski <kuba@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>, Eric Dumazet
 <edumazet@google.com>, Paolo Abeni <pabeni@redhat.com>, Dmitry Safonov
 <0x7f454c46@gmail.com>, Heiner Kallweit <hkallweit1@gmail.com>,
 nex.sw.ncis.osdt.itp.upstreaming@intel.com, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse
 shadow warnings throughout the file
Message-ID: <20240329131857.730c6528@kernel.org>
In-Reply-To: <20240329170000.3241460-3-aleksander.lobakin@intel.com>
References: <20240329170000.3241460-1-aleksander.lobakin@intel.com>
	<20240329170000.3241460-3-aleksander.lobakin@intel.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Return-Path: linux-kernel+bounces-125384-steffen.klassert=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 29 Mar 2024 20:19:25.8902
 (UTC)
X-MS-Exchange-Organization-Network-Message-Id: d20bea01-e9bc-4d2c-c411-08dc502d879f
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.201
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-01.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=mbx-essen-02.secunet.de:TOTAL-HUB=0.393|SMR=0.326(SMRDE=0.004|SMRC=0.321(SMRCL=0.102|X-SMRCR=0.321))|CAT=0.065(CATOS=0.001
 (CATSM=0.001)|CATRESL=0.026(CATRESLP2R=0.017)|CATORES=0.033(CATRS=0.033(CATRS-Index
 Routing Agent=0.031 ))|CATORT=0.001(CATRT=0.001));2024-03-29T20:19:26.301Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-01.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 7871
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRV=cas-essen-01.secunet.de:TOTAL-FE=0.017|SMR=0.008(SMRPI=0.006(SMRPI-FrontendProxyAgent=0.006))|SMS=0.010
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-essen-02
X-MS-Exchange-Organization-RulesExecuted: mbx-essen-02
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAWYDAAAPAAADH4sIAAAAAAAEAL1UUW/bRgymZEu25Xgtin
 av45sTLEsip2gbBVlRJC0QIG0HBF0xrK1wltj4UFnn3EmOPexX7BeP
 J9lLm2SLkYcd5IN8JL+PH8nTX923Ob7SchMHe/haaBzsDB5j+Cza2e
 EHf9wJeX+R0UzkKWk8UUPxReZ4oVVBUS/4GVMtp6TNdk7FNhUj0vZF
 5gVl2zKdfK62uJjp2VYShXt7g2gvwguhc5mfRZhSkgktCqlyNCORqg
 uDAjOViAynQksxzAh//+l9bfto+dCC4J+4XJqKUufIrNLynMdjMR9S
 bAo1Wc/PN/H46JdX8dHL08P43Zt3py+P1otZfL6xiUb+QfW+sV/hVu
 sSd7E+WdsWC0qyMqVKJf9SmsbnJZVktkZRuPs0CsMIc1sSpNnElirF
 z1qNcSwSrbB/U3b9mpWjr7P+s2JNBg++Ulfoea2N/2ziGRVxSiZhIY
 XQRVyMtNnYxw//IegOArlpT1eUt0xvIQ6/adVy8XRUwvZvy+3KulXW
 p7sOZK1tomkqVWm+GUtpkDFolTHYXblMN0zB7v9dKOtzOhHaVPf4Tp
 ULn3x1l818PFQZ9m3C/cvbnCMJnUn+dqic7syitDyTuciy+aI5XNq6
 Lb3gGFOV9ws0RMh4hnBYyizlpPBCFiM8Ofn19UGI7w/CAR4ehL2AO4
 PH/OGo4arYTH4hTNR4ksmE+86hjMQHKYNRIkpDi4PxRGakewGPhSnK
 iUy38FBYhLkq0ahsah3ZWDEbNSbmycWYzHN8kaZcDmUl94LSfk5Noj
 SxtsqRw/Kz51YQgAuNBniuA11+7Huz6XhtgLbT8QA88DsQtKDtVTtb
 28DnfhO8pgMd3sFzHLcJwFEOgAONFnS6sMbODrjs2YZuy+lZB7jnQ4
 udHoLPODWIa+ngfoXDVk6jCQ3emta6XjP6DvSgxVYmagCbm65N2/pw
 MhzoXYF1utYNfmiAz+cPqnOrCzxWyujtKpZNgWWJrrNYfKdRy7nCco
 nmrFVpPLKY8NuKxanRuD6ufQ/+TeCN1NcEfl9Rf/Dhu1vZ64pxa3zo
 cBT7u7ZTHNVaMTaAbpXMoq11JnV6S3XuonSswHFrCezG57bvFfga9O
 pGLEkDdvbtdF2ORP20bJ42YeZln87fEYsguz0IAAABDs8BUmV0cmll
 dmVyT3BlcmF0b3IsMTAsMTtSZXRyaWV2ZXJPcGVyYXRvciwxMSwyO1
 Bvc3REb2NQYXJzZXJPcGVyYXRvciwxMCwyO1Bvc3REb2NQYXJzZXJP
 cGVyYXRvciwxMSwwO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcG
 VyYXRvciwxMCwyO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcGVy
 YXRvciwxMSwwO1RyYW5zcG9ydFdyaXRlclByb2R1Y2VyLDIwLDE3
X-MS-Exchange-Forest-IndexAgent: 1 1092
X-MS-Exchange-Forest-EmailMessageHash: 7E5A4F6D
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent

On Fri, 29 Mar 2024 18:00:00 +0100 Alexander Lobakin wrote:
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:9: warning: declaration shadows a local variable [-Wshadow]
>  1992 |         return netif_txq_maybe_stop(nq, IDPF_DESC_UNUSED(tx_q), size, size);
>       |                ^
> ./include/net/netdev_queues.h:137:11: note: expanded from macro 'netif_txq_maybe_stop'
>   137 |                         _res = netif_txq_try_stop(txq, get_desc, start_thrs); \
>       |                                ^
> ./include/net/netdev_queues.h:92:7: note: expanded from macro 'netif_txq_try_stop'
>    92 |                 int _res;                                               \
>       |                     ^
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:9: note: previous declaration is here
> ./include/net/netdev_queues.h:133:7: note: expanded from macro 'netif_txq_maybe_stop'
>   133 |                 int _res;                                               \
>       |                     ^
> 
> Sparse:
> 
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: warning: symbol '_res' shadows an earlier one
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: originally declared here

I don't see these building with LLVM=1 W=12 C=1
and I really don't like complicating the code because the compiler
is stupid. Can't you solve this with some renames? Add another
underscore or something?


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

* Re: [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse shadow warnings throughout the file
@ 2024-03-29 20:53       ` Jakub Kicinski
  0 siblings, 0 replies; 11+ messages in thread
From: Jakub Kicinski @ 2024-03-29 20:53 UTC (permalink / raw
  To: Alexander Lobakin
  Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Dmitry Safonov,
	Heiner Kallweit, nex.sw.ncis.osdt.itp.upstreaming, netdev,
	linux-kernel

On Fri, 29 Mar 2024 13:18:57 -0700 Jakub Kicinski wrote:
> > Sparse:
> > 
> > drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: warning: symbol '_res' shadows an earlier one
> > drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: originally declared here  
> 
> I don't see these building with LLVM=1 W=12 C=1
> and I really don't like complicating the code because the compiler
> is stupid. Can't you solve this with some renames? Add another
> underscore or something?

I'm stupid I tried on the test branch which already had your fix..

This is enough:

diff --git a/include/net/netdev_queues.h b/include/net/netdev_queues.h
index 1ec408585373..2270fbb99cf7 100644
--- a/include/net/netdev_queues.h
+++ b/include/net/netdev_queues.h
@@ -89,7 +89,7 @@ struct netdev_stat_ops {
 
 #define netif_txq_try_stop(txq, get_desc, start_thrs)			\
 	({								\
-		int _res;						\
+		int __res;						\
 									\
 		netif_tx_stop_queue(txq);				\
 		/* Producer index and stop bit must be visible		\
@@ -101,12 +101,12 @@ struct netdev_stat_ops {
 		/* We need to check again in a case another		\
 		 * CPU has just made room available.			\
 		 */							\
-		_res = 0;						\
+		__res = 0;						\
 		if (unlikely(get_desc >= start_thrs)) {			\
 			netif_tx_start_queue(txq);			\
-			_res = -1;					\
+			__res = -1;					\
 		}							\
-		_res;							\
+		__res;							\
 	})								\
 
 /**

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

* Re: [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse shadow warnings throughout the file
@ 2024-03-29 20:53       ` Jakub Kicinski
  0 siblings, 0 replies; 11+ messages in thread
From: Jakub Kicinski @ 2024-03-29 20:53 UTC (permalink / raw
  To: Alexander Lobakin
  Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Dmitry Safonov,
	Heiner Kallweit, nex.sw.ncis.osdt.itp.upstreaming, netdev,
	linux-kernel

On Fri, 29 Mar 2024 13:18:57 -0700 Jakub Kicinski wrote:
> > Sparse:
> > 
> > drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: warning: symbol '_res' shadows an earlier one
> > drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: originally declared here  
> 
> I don't see these building with LLVM=1 W=12 C=1
> and I really don't like complicating the code because the compiler
> is stupid. Can't you solve this with some renames? Add another
> underscore or something?

I'm stupid I tried on the test branch which already had your fix..

This is enough:

diff --git a/include/net/netdev_queues.h b/include/net/netdev_queues.h
index 1ec408585373..2270fbb99cf7 100644
--- a/include/net/netdev_queues.h
+++ b/include/net/netdev_queues.h
@@ -89,7 +89,7 @@ struct netdev_stat_ops {
 
 #define netif_txq_try_stop(txq, get_desc, start_thrs)			\
 	({								\
-		int _res;						\
+		int __res;						\
 									\
 		netif_tx_stop_queue(txq);				\
 		/* Producer index and stop bit must be visible		\
@@ -101,12 +101,12 @@ struct netdev_stat_ops {
 		/* We need to check again in a case another		\
 		 * CPU has just made room available.			\
 		 */							\
-		_res = 0;						\
+		__res = 0;						\
 		if (unlikely(get_desc >= start_thrs)) {			\
 			netif_tx_start_queue(txq);			\
-			_res = -1;					\
+			__res = -1;					\
 		}							\
-		_res;							\
+		__res;							\
 	})								\
 
 /**

X-sender: <netdev+bounces-83461-steffen.klassert=secunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=rfc822;steffen.klassert@secunet.com NOTIFY=NEVER; X-ExtendedProps=BQAVABYAAgAAAAUAFAARAPDFCS25BAlDktII2g02frgPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAGIAAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249U3RlZmZlbiBLbGFzc2VydDY4YwUACwAXAL4AAACheZxkHSGBRqAcAp3ukbifQ049REI2LENOPURhdGFiYXNlcyxDTj1FeGNoYW5nZSBBZG1pbmlzdHJhdGl2ZSBHcm91cCAoRllESUJPSEYyM1NQRExUKSxDTj1BZG1pbmlzdHJhdGl2ZSBHcm91cHMsQ049c2VjdW5ldCxDTj1NaWNyb3NvZnQgRXhjaGFuZ2UsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1zZWN1bmV0LERDPWRlBQAOABEABiAS9uuMOkqzwmEZDvWNNQUAHQAPAAwAAABtYngtZXNzZW4tMDIFADwAAgAADwA2AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50LkRpc3BsYXlOYW1lDwARAAAAS2xhc3NlcnQsIFN0ZWZmZW4FAAwAAgAABQBsAAIAAAUAWAAXAEoAAADwxQktuQQJQ5LSCNoNNn64Q049S2xhc3NlcnQgU3RlZmZlbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ==
X-CreatedBy: MSExchange15
X-HeloDomain: b.mx.secunet.com
X-ExtendedProps: BQBjAAoAbUamlidQ3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAAQAFCABAAAAHAAAAHN0ZWZmZW4ua2xhc3NlcnRAc2VjdW5ldC5jb20FAAYAAgABBQApAAIAAQ8ACQAAAENJQXVkaXRlZAIAAQUAAgAHAAEAAAAFAAMABwAAAAAABQAFAAIAAQUAYgAKAMsAAADLigAABQBkAA8AAwAAAEh1Yg==
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 62.96.220.37
X-EndOfInjectedXHeaders: 11324
Received: from cas-essen-02.secunet.de (10.53.40.202) by
 mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.37; Fri, 29 Mar 2024 21:53:57 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-02.secunet.de
 (10.53.40.202) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
 Transport; Fri, 29 Mar 2024 21:53:57 +0100
Received: from localhost (localhost [127.0.0.1])
	by b.mx.secunet.com (Postfix) with ESMTP id EF6BB2032C
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 21:53:56 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=2.1
	tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.099, DKIM_SIGNED=0.1,
	DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MAILING_LIST_MULTI=-1,
	RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
	autolearn=ham autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
	dkim=pass (2048-bit key) header.d=kernel.org
Received: from b.mx.secunet.com ([127.0.0.1])
	by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id uqhsOYZd3Ue1 for <steffen.klassert@secunet.com>;
	Fri, 29 Mar 2024 21:53:56 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=139.178.88.99; helo=sv.mirrors.kernel.org; envelope-from=netdev+bounces-83461-steffen.klassert=secunet.com@vger.kernel.org; receiver=steffen.klassert@secunet.com 
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com 18C0E20270
Authentication-Results: b.mx.secunet.com;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nt5XZQ8A"
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by b.mx.secunet.com (Postfix) with ESMTPS id 18C0E20270
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 21:53:56 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by sv.mirrors.kernel.org (Postfix) with ESMTPS id AEF532847D8
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 20:53:54 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 634AF86130;
	Fri, 29 Mar 2024 20:53:47 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nt5XZQ8A"
X-Original-To: netdev@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id BEB043FBB4;
	Fri, 29 Mar 2024 20:53:46 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1711745626; cv=none; b=CVPCGk9LD0NbPjQV8T2NNphifh6hmBZaegACNK3HaX/lTWENaRN6Fdlf4knmT1jZjTtE/cxgVHj9nX5tC5bpS5XTf8CDbYoJ8g3k8LTz7UeL48U8g6RJk1nD/BJIk/d7y/S9r0GuQb3dVmwVSdggts92/Fgf7pXeAN/MxmrFpa4=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1711745626; c=relaxed/simple;
	bh=DPU/cpMX8JgPzOh54Wy5Z1joAaXrPLw4+pp0/2XrYwo=;
	h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=p/YgEleA7dhqMltk+cpaDAI5CB6Lxj8GtF3ftBqkh9p0yRW9z2he+RRe91fZHBJ+LqVhIsvHLMH0FT77gqRr4dYhRzsYZMFuBhQLc59ydGn2GoVeT3YNhGEpWwsNRFQlNo3N0K05H4mJRNmROttjq61J8Xwbz+5tyOFWqpx1HK4=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nt5XZQ8A; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75A95C433C7;
	Fri, 29 Mar 2024 20:53:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1711745625;
	bh=DPU/cpMX8JgPzOh54Wy5Z1joAaXrPLw4+pp0/2XrYwo=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=nt5XZQ8AuFdzkpc2dRk4glfwOAVOcm1EdgvmJH132ePhRwjx5yZG7K5MDJf7XEaXf
	 DNUmTCxPOgEyg82a0x+w/HjPxm0ksMkeaCOMP/vZCOd9Xzx3wgYHLnO9JCshz15SQT
	 rMXaDnaBpPXSvZDu8fKKgkDjwpyBmbuvSAJQVLwDGgLMXs4WbAgKj4Swf1TEL7R6BY
	 7WPgwSohXsmR/Hlvjyyvl3pMa00trccpz/7FsrFsTzXSAyPZ+F+H/We6eRrIqvKQTE
	 Nt2XqeSYRkKbZraS9gxLxNtOsHaK4zygIPknpsWEa2Jr/9wVwM+l4r1fJB94AFXUB9
	 5iFtrKKt4p58Q==
Date: Fri, 29 Mar 2024 13:53:44 -0700
From: Jakub Kicinski <kuba@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>, Eric Dumazet
 <edumazet@google.com>, Paolo Abeni <pabeni@redhat.com>, Dmitry Safonov
 <0x7f454c46@gmail.com>, Heiner Kallweit <hkallweit1@gmail.com>,
 nex.sw.ncis.osdt.itp.upstreaming@intel.com, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse
 shadow warnings throughout the file
Message-ID: <20240329135344.1a310f31@kernel.org>
In-Reply-To: <20240329131857.730c6528@kernel.org>
References: <20240329170000.3241460-1-aleksander.lobakin@intel.com>
	<20240329170000.3241460-3-aleksander.lobakin@intel.com>
	<20240329131857.730c6528@kernel.org>
Precedence: bulk
X-Mailing-List: netdev@vger.kernel.org
List-Id: <netdev.vger.kernel.org>
List-Subscribe: <mailto:netdev+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:netdev+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Return-Path: netdev+bounces-83461-steffen.klassert=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 29 Mar 2024 20:53:57.0213
 (UTC)
X-MS-Exchange-Organization-Network-Message-Id: adfa49c9-4e8d-4796-70e9-08dc50325a1d
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.202
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-02.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=mbx-essen-02.secunet.de:TOTAL-HUB=0.369|SMR=0.323(SMRDE=0.004|SMRC=0.318(SMRCL=0.104|X-SMRCR=0.317))|CAT=0.045(CATOS=0.001
 |CATRESL=0.010(CATRESLP2R=0.005)|CATORES=0.029(CATRS=0.029(CATRS-Transport
 Rule Agent=0.001 |CATRS-Index Routing
 Agent=0.027))|CATORT=0.001(CATRT=0.001));2024-03-29T20:53:57.405Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-02.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 7888
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRV=cas-essen-02.secunet.de:TOTAL-FE=0.014|SMR=0.004(SMRPI=0.002(SMRPI-FrontendProxyAgent=0.002))|SMS=0.009
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-essen-02
X-MS-Exchange-Organization-RulesExecuted: mbx-essen-02
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAXEEAAAPAAADH4sIAAAAAAAEAK1UW2/bNhSmLFm+xO6AtM
 CAPR1gD0ns+CLHqWMPSTsECNAtxQrs0pcCBi3RNhdZcknKjlHkea/7
 N/t7O6TsNF2E3DpClqnDc77zfYeH/Gf7lwjOBN+HTh/eUgGddqcL3s
 HAOxoc9qDR7rXb8BO9SEbwM/d5JC84LEWs2KBaPoET+HVOhVx/pJZA
 8AUTshUx1WJqyoSe8EixsMWD+di8hupSXDb9gdfvdwbeywEsqYh4NB
 mAXM1GcQg7Q8HkDsgpDeKlBBoBoyLkTEAcsa/IEws+4RENwxUEzA+p
 YAFgqIbUqG8giKMdBZIxQEjJYJTwMEBmsORqCufnf7w99uD9sdeB02
 NPh9AowDDBUkwTHfILBn48m4fcp0oHIxYaAoRjPk0kWxtmcx4yoVG4
 BKmSOQ+acEo1xipOQMbhQrviosku4xnDTBGdMfkKfgwCTB5r5RohiQ
 Kshh8LhiKNKwZGk1fVcrX8Zme2hkeqSnAUHUeGg2JSwUjQyJ/Ccsrx
 TUPUEqwAK69JCBjzy2ZTo/ymieDDojiZTAfaFPDxGBqNCVdAsfZ+mA
 TMbAj+ArYYfkxYwmRzCqO7VqtljuQvwWN+t310eHR40DtoNjudXns8
 GvX7/rgHXrv9stutlhuNxt2ZquV6vX5futevoXHU3+9B3bzxUyqR+A
 rWnlJRNYznEj5pkfB9wMY8YnqV65b6OFRihU7xfBc/9mHC1DBg0t9H
 GCrUUE2F3INb4wNCrcfup9vLjxkI1fiPCTsf9KH54fFQ9SyoJ2DdEP
 i1IwNqU31T+HQzdfn37iOZAdWqwTsRB4mP90naevoUa1wYYSvPEn0o
 GCy45KOQfQGlW8dre/t4AdTX/3e2T0bq97qT8AiqGPwp8y+ATiiPkA
 hQ8CleDutTfZ8KqMHpu9/xoEr4UzOeUbxgRBzPgC4oDylSbz6wIFBr
 3VPF7JHRh7pv4Bja/0MfDp+IlSGQj2E3ifTFHK52N+cVTo5vntg9uH
 0q72jpG/2oIe5tyIxabcZaZ8N7oNCMWl1DPRIrQ+DVw0hkQWU1w2Mb
 YQ2V2QxPwLoh8CrjUn4kFIK1ajX9T0iO2DbJ5yyyhY+eO46VLxJStE
 p5QvLExadIcF5xyXaBFNHBfLoOyTsWKeGb5C0r5xCCgTkN6BRIySUl
 hEV/xDdRpQfGlskW+jiaTg49MSQlYELyFiFoxxDjbOPEWPLohnaXFF
 LwCqlqIYaASVpBZ5cUrwEdk9o4IE8kvIV50adEnuEn4qTZc2lBSD5F
 TtEcnU7zMZhbDimk2dNV1yJVUkgRsow24lTIs4pVdQlxSSXLp5BhtJ
 A5Cna0Xiv3eW64ods3pGCIbWmqFtk2Sjds87ZFinru4lJZy0+0kZzZ
 2u1vXdfnRi16mxoN0n3axDup2oL17eetsuwb2+Z+SeK7FCpn1KZ1RE
 mm3LVrWulTIle25RolZ5vJac40yoZ0cUO6i5MXBi2FtUkPQwyBs83k
 L8sm5/a/2OuiUhEMAAABDs8BUmV0cmlldmVyT3BlcmF0b3IsMTAsMT
 tSZXRyaWV2ZXJPcGVyYXRvciwxMSwxO1Bvc3REb2NQYXJzZXJPcGVy
 YXRvciwxMCwwO1Bvc3REb2NQYXJzZXJPcGVyYXRvciwxMSwwO1Bvc3
 RXb3JkQnJlYWtlckRpYWdub3N0aWNPcGVyYXRvciwxMCwxO1Bvc3RX
 b3JkQnJlYWtlckRpYWdub3N0aWNPcGVyYXRvciwxMSwwO1RyYW5zcG
 9ydFdyaXRlclByb2R1Y2VyLDIwLDE2
X-MS-Exchange-Forest-IndexAgent: 1 1359
X-MS-Exchange-Forest-EmailMessageHash: 5D566706
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent

On Fri, 29 Mar 2024 13:18:57 -0700 Jakub Kicinski wrote:
> > Sparse:
> > 
> > drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: warning: symbol '_res' shadows an earlier one
> > drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: originally declared here  
> 
> I don't see these building with LLVM=1 W=12 C=1
> and I really don't like complicating the code because the compiler
> is stupid. Can't you solve this with some renames? Add another
> underscore or something?

I'm stupid I tried on the test branch which already had your fix..

This is enough:

diff --git a/include/net/netdev_queues.h b/include/net/netdev_queues.h
index 1ec408585373..2270fbb99cf7 100644
--- a/include/net/netdev_queues.h
+++ b/include/net/netdev_queues.h
@@ -89,7 +89,7 @@ struct netdev_stat_ops {
 
 #define netif_txq_try_stop(txq, get_desc, start_thrs)			\
 	({								\
-		int _res;						\
+		int __res;						\
 									\
 		netif_tx_stop_queue(txq);				\
 		/* Producer index and stop bit must be visible		\
@@ -101,12 +101,12 @@ struct netdev_stat_ops {
 		/* We need to check again in a case another		\
 		 * CPU has just made room available.			\
 		 */							\
-		_res = 0;						\
+		__res = 0;						\
 		if (unlikely(get_desc >= start_thrs)) {			\
 			netif_tx_start_queue(txq);			\
-			_res = -1;					\
+			__res = -1;					\
 		}							\
-		_res;							\
+		__res;							\
 	})								\
 
 /**

X-sender: <linux-kernel+bounces-125414-steffen.klassert=secunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=rfc822;steffen.klassert@secunet.com NOTIFY=NEVER; X-ExtendedProps=BQAVABYAAgAAAAUAFAARAPDFCS25BAlDktII2g02frgPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAGIAAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249U3RlZmZlbiBLbGFzc2VydDY4YwUACwAXAL4AAACheZxkHSGBRqAcAp3ukbifQ049REI2LENOPURhdGFiYXNlcyxDTj1FeGNoYW5nZSBBZG1pbmlzdHJhdGl2ZSBHcm91cCAoRllESUJPSEYyM1NQRExUKSxDTj1BZG1pbmlzdHJhdGl2ZSBHcm91cHMsQ049c2VjdW5ldCxDTj1NaWNyb3NvZnQgRXhjaGFuZ2UsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1zZWN1bmV0LERDPWRlBQAOABEABiAS9uuMOkqzwmEZDvWNNQUAHQAPAAwAAABtYngtZXNzZW4tMDIFADwAAgAADwA2AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50LkRpc3BsYXlOYW1lDwARAAAAS2xhc3NlcnQsIFN0ZWZmZW4FAAwAAgAABQBsAAIAAAUAWAAXAEoAAADwxQktuQQJQ5LSCNoNNn64Q049S2xhc3NlcnQgU3RlZmZlbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ==
X-CreatedBy: MSExchange15
X-HeloDomain: b.mx.secunet.com
X-ExtendedProps: BQBjAAoAbUamlidQ3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAAQAFCABAAAAHAAAAHN0ZWZmZW4ua2xhc3NlcnRAc2VjdW5ldC5jb20FAAYAAgABBQApAAIAAQ8ACQAAAENJQXVkaXRlZAIAAQUAAgAHAAEAAAAFAAMABwAAAAAABQAFAAIAAQUAYgAKAM0AAADLigAABQBkAA8AAwAAAEh1Yg==
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 62.96.220.37
X-EndOfInjectedXHeaders: 11325
Received: from cas-essen-02.secunet.de (10.53.40.202) by
 mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.37; Fri, 29 Mar 2024 21:54:14 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-02.secunet.de
 (10.53.40.202) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
 Transport; Fri, 29 Mar 2024 21:54:14 +0100
Received: from localhost (localhost [127.0.0.1])
	by b.mx.secunet.com (Postfix) with ESMTP id 5E26F2032C
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 21:54:14 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=2.1
	tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.099, DKIM_SIGNED=0.1,
	DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MAILING_LIST_MULTI=-1,
	RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
	autolearn=unavailable autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
	dkim=pass (2048-bit key) header.d=kernel.org
Received: from b.mx.secunet.com ([127.0.0.1])
	by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id mtnP-P3F68RA for <steffen.klassert@secunet.com>;
	Fri, 29 Mar 2024 21:54:09 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.75.48.161; helo=sy.mirrors.kernel.org; envelope-from=linux-kernel+bounces-125414-steffen.klassert=secunet.com@vger.kernel.org; receiver=steffen.klassert@secunet.com 
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com 49DBA20270
Authentication-Results: b.mx.secunet.com;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nt5XZQ8A"
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by b.mx.secunet.com (Postfix) with ESMTPS id 49DBA20270
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 21:54:09 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by sy.mirrors.kernel.org (Postfix) with ESMTPS id D8C98B21EC3
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 20:54:05 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 1910013B59A;
	Fri, 29 Mar 2024 20:53:49 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nt5XZQ8A"
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id BEB043FBB4;
	Fri, 29 Mar 2024 20:53:46 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1711745626; cv=none; b=CVPCGk9LD0NbPjQV8T2NNphifh6hmBZaegACNK3HaX/lTWENaRN6Fdlf4knmT1jZjTtE/cxgVHj9nX5tC5bpS5XTf8CDbYoJ8g3k8LTz7UeL48U8g6RJk1nD/BJIk/d7y/S9r0GuQb3dVmwVSdggts92/Fgf7pXeAN/MxmrFpa4=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1711745626; c=relaxed/simple;
	bh=DPU/cpMX8JgPzOh54Wy5Z1joAaXrPLw4+pp0/2XrYwo=;
	h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=p/YgEleA7dhqMltk+cpaDAI5CB6Lxj8GtF3ftBqkh9p0yRW9z2he+RRe91fZHBJ+LqVhIsvHLMH0FT77gqRr4dYhRzsYZMFuBhQLc59ydGn2GoVeT3YNhGEpWwsNRFQlNo3N0K05H4mJRNmROttjq61J8Xwbz+5tyOFWqpx1HK4=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nt5XZQ8A; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75A95C433C7;
	Fri, 29 Mar 2024 20:53:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1711745625;
	bh=DPU/cpMX8JgPzOh54Wy5Z1joAaXrPLw4+pp0/2XrYwo=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=nt5XZQ8AuFdzkpc2dRk4glfwOAVOcm1EdgvmJH132ePhRwjx5yZG7K5MDJf7XEaXf
	 DNUmTCxPOgEyg82a0x+w/HjPxm0ksMkeaCOMP/vZCOd9Xzx3wgYHLnO9JCshz15SQT
	 rMXaDnaBpPXSvZDu8fKKgkDjwpyBmbuvSAJQVLwDGgLMXs4WbAgKj4Swf1TEL7R6BY
	 7WPgwSohXsmR/Hlvjyyvl3pMa00trccpz/7FsrFsTzXSAyPZ+F+H/We6eRrIqvKQTE
	 Nt2XqeSYRkKbZraS9gxLxNtOsHaK4zygIPknpsWEa2Jr/9wVwM+l4r1fJB94AFXUB9
	 5iFtrKKt4p58Q==
Date: Fri, 29 Mar 2024 13:53:44 -0700
From: Jakub Kicinski <kuba@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>, Eric Dumazet
 <edumazet@google.com>, Paolo Abeni <pabeni@redhat.com>, Dmitry Safonov
 <0x7f454c46@gmail.com>, Heiner Kallweit <hkallweit1@gmail.com>,
 nex.sw.ncis.osdt.itp.upstreaming@intel.com, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse
 shadow warnings throughout the file
Message-ID: <20240329135344.1a310f31@kernel.org>
In-Reply-To: <20240329131857.730c6528@kernel.org>
References: <20240329170000.3241460-1-aleksander.lobakin@intel.com>
	<20240329170000.3241460-3-aleksander.lobakin@intel.com>
	<20240329131857.730c6528@kernel.org>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Return-Path: linux-kernel+bounces-125414-steffen.klassert=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 29 Mar 2024 20:54:14.4167
 (UTC)
X-MS-Exchange-Organization-Network-Message-Id: 7b3221dc-8701-4ced-c3c0-08dc5032647b
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.202
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-02.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=mbx-essen-02.secunet.de:TOTAL-HUB=0.374|SMR=0.322(SMRDE=0.004|SMRC=0.317(SMRCL=0.102|X-SMRCR=0.316))|CAT=0.050(CATOS=0.001
 |CATRESL=0.008(CATRESLP2R=0.003)|CATORES=0.037(CATRS=0.037(CATRS-Transport
 Rule Agent=0.002 (X-ETREX=0.001)|CATRS-Index Routing
 Agent=0.033)));2024-03-29T20:54:14.813Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-02.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 7902
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRV=cas-essen-02.secunet.de:TOTAL-FE=0.023|SMR=0.012(SMRPI=0.009(SMRPI-FrontendProxyAgent=0.009))|SMS=0.011
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-essen-02
X-MS-Exchange-Organization-RulesExecuted: mbx-essen-02
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAXEEAAAPAAADH4sIAAAAAAAEAK1UW2/bNhSmLFm+xO6AtM
 CAPR1gD0ns+CLHqWMPSTsECNAtxQrs0pcCBi3RNhdZcknKjlHkea/7
 N/t7O6TsNF2E3DpClqnDc77zfYeH/Gf7lwjOBN+HTh/eUgGddqcL3s
 HAOxoc9qDR7rXb8BO9SEbwM/d5JC84LEWs2KBaPoET+HVOhVx/pJZA
 8AUTshUx1WJqyoSe8EixsMWD+di8hupSXDb9gdfvdwbeywEsqYh4NB
 mAXM1GcQg7Q8HkDsgpDeKlBBoBoyLkTEAcsa/IEws+4RENwxUEzA+p
 YAFgqIbUqG8giKMdBZIxQEjJYJTwMEBmsORqCufnf7w99uD9sdeB02
 NPh9AowDDBUkwTHfILBn48m4fcp0oHIxYaAoRjPk0kWxtmcx4yoVG4
 BKmSOQ+acEo1xipOQMbhQrviosku4xnDTBGdMfkKfgwCTB5r5RohiQ
 Kshh8LhiKNKwZGk1fVcrX8Zme2hkeqSnAUHUeGg2JSwUjQyJ/Ccsrx
 TUPUEqwAK69JCBjzy2ZTo/ymieDDojiZTAfaFPDxGBqNCVdAsfZ+mA
 TMbAj+ArYYfkxYwmRzCqO7VqtljuQvwWN+t310eHR40DtoNjudXns8
 GvX7/rgHXrv9stutlhuNxt2ZquV6vX5futevoXHU3+9B3bzxUyqR+A
 rWnlJRNYznEj5pkfB9wMY8YnqV65b6OFRihU7xfBc/9mHC1DBg0t9H
 GCrUUE2F3INb4wNCrcfup9vLjxkI1fiPCTsf9KH54fFQ9SyoJ2DdEP
 i1IwNqU31T+HQzdfn37iOZAdWqwTsRB4mP90naevoUa1wYYSvPEn0o
 GCy45KOQfQGlW8dre/t4AdTX/3e2T0bq97qT8AiqGPwp8y+ATiiPkA
 hQ8CleDutTfZ8KqMHpu9/xoEr4UzOeUbxgRBzPgC4oDylSbz6wIFBr
 3VPF7JHRh7pv4Bja/0MfDp+IlSGQj2E3ifTFHK52N+cVTo5vntg9uH
 0q72jpG/2oIe5tyIxabcZaZ8N7oNCMWl1DPRIrQ+DVw0hkQWU1w2Mb
 YQ2V2QxPwLoh8CrjUn4kFIK1ajX9T0iO2DbJ5yyyhY+eO46VLxJStE
 p5QvLExadIcF5xyXaBFNHBfLoOyTsWKeGb5C0r5xCCgTkN6BRIySUl
 hEV/xDdRpQfGlskW+jiaTg49MSQlYELyFiFoxxDjbOPEWPLohnaXFF
 LwCqlqIYaASVpBZ5cUrwEdk9o4IE8kvIV50adEnuEn4qTZc2lBSD5F
 TtEcnU7zMZhbDimk2dNV1yJVUkgRsow24lTIs4pVdQlxSSXLp5BhtJ
 A5Cna0Xiv3eW64ods3pGCIbWmqFtk2Sjds87ZFinru4lJZy0+0kZzZ
 2u1vXdfnRi16mxoN0n3axDup2oL17eetsuwb2+Z+SeK7FCpn1KZ1RE
 mm3LVrWulTIle25RolZ5vJac40yoZ0cUO6i5MXBi2FtUkPQwyBs83k
 L8sm5/a/2OuiUhEMAAABDs8BUmV0cmlldmVyT3BlcmF0b3IsMTAsMT
 tSZXRyaWV2ZXJPcGVyYXRvciwxMSwzO1Bvc3REb2NQYXJzZXJPcGVy
 YXRvciwxMCwxO1Bvc3REb2NQYXJzZXJPcGVyYXRvciwxMSwwO1Bvc3
 RXb3JkQnJlYWtlckRpYWdub3N0aWNPcGVyYXRvciwxMCwxO1Bvc3RX
 b3JkQnJlYWtlckRpYWdub3N0aWNPcGVyYXRvciwxMSwwO1RyYW5zcG
 9ydFdyaXRlclByb2R1Y2VyLDIwLDE4
X-MS-Exchange-Forest-IndexAgent: 1 1359
X-MS-Exchange-Forest-EmailMessageHash: 5D566706
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent

On Fri, 29 Mar 2024 13:18:57 -0700 Jakub Kicinski wrote:
> > Sparse:
> > 
> > drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: warning: symbol '_res' shadows an earlier one
> > drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: originally declared here  
> 
> I don't see these building with LLVM=1 W=12 C=1
> and I really don't like complicating the code because the compiler
> is stupid. Can't you solve this with some renames? Add another
> underscore or something?

I'm stupid I tried on the test branch which already had your fix..

This is enough:

diff --git a/include/net/netdev_queues.h b/include/net/netdev_queues.h
index 1ec408585373..2270fbb99cf7 100644
--- a/include/net/netdev_queues.h
+++ b/include/net/netdev_queues.h
@@ -89,7 +89,7 @@ struct netdev_stat_ops {
 
 #define netif_txq_try_stop(txq, get_desc, start_thrs)			\
 	({								\
-		int _res;						\
+		int __res;						\
 									\
 		netif_tx_stop_queue(txq);				\
 		/* Producer index and stop bit must be visible		\
@@ -101,12 +101,12 @@ struct netdev_stat_ops {
 		/* We need to check again in a case another		\
 		 * CPU has just made room available.			\
 		 */							\
-		_res = 0;						\
+		__res = 0;						\
 		if (unlikely(get_desc >= start_thrs)) {			\
 			netif_tx_start_queue(txq);			\
-			_res = -1;					\
+			__res = -1;					\
 		}							\
-		_res;							\
+		__res;							\
 	})								\
 
 /**


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

* Re: [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse shadow warnings throughout the file
  2024-03-29 20:53       ` Jakub Kicinski
  (?)
@ 2024-04-02 11:53       ` Alexander Lobakin
  2024-04-02 12:45         ` Eric Dumazet
  -1 siblings, 1 reply; 11+ messages in thread
From: Alexander Lobakin @ 2024-04-02 11:53 UTC (permalink / raw
  To: Jakub Kicinski
  Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Dmitry Safonov,
	Heiner Kallweit, nex.sw.ncis.osdt.itp.upstreaming, netdev,
	linux-kernel

From: Jakub Kicinski <kuba@kernel.org>
Date: Fri, 29 Mar 2024 13:53:44 -0700

> On Fri, 29 Mar 2024 13:18:57 -0700 Jakub Kicinski wrote:
>>> Sparse:
>>>
>>> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: warning: symbol '_res' shadows an earlier one
>>> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: originally declared here  
>>
>> I don't see these building with LLVM=1 W=12 C=1
>> and I really don't like complicating the code because the compiler
>> is stupid. Can't you solve this with some renames? Add another

It's not the compiler, its warnings are valid actually. Shadowing makes
it very easy to confuse variables and make bugs...

>> underscore or something?
> 
> I'm stupid I tried on the test branch which already had your fix..

:D Sometimes it happens.

> 
> This is enough:
> 
> diff --git a/include/net/netdev_queues.h b/include/net/netdev_queues.h
> index 1ec408585373..2270fbb99cf7 100644
> --- a/include/net/netdev_queues.h
> +++ b/include/net/netdev_queues.h
> @@ -89,7 +89,7 @@ struct netdev_stat_ops {
>  
>  #define netif_txq_try_stop(txq, get_desc, start_thrs)			\
>  	({								\
> -		int _res;						\
> +		int __res;						\
>  									\
>  		netif_tx_stop_queue(txq);				\
>  		/* Producer index and stop bit must be visible		\
> @@ -101,12 +101,12 @@ struct netdev_stat_ops {
>  		/* We need to check again in a case another		\
>  		 * CPU has just made room available.			\
>  		 */							\
> -		_res = 0;						\
> +		__res = 0;						\
>  		if (unlikely(get_desc >= start_thrs)) {			\
>  			netif_tx_start_queue(txq);			\
> -			_res = -1;					\
> +			__res = -1;					\
>  		}							\
> -		_res;							\
> +		__res;							\
>  	})								\
>  
>  /**

But what if there's a function which calls one of these functions and
already has _res or __res or something? I know renaming is enough for
the warnings I mentioned, but without __UNIQUE_ID() anything can happen
anytime, so I wanted to fix that once and for all :z

I already saw some macros which have a layer of indirection for
__UNIQUE_ID(), but previously they didn't and then there were fixes
which added underscores, renamed variables etc etc...

Thanks,
Olek

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

* Re: [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse shadow warnings throughout the file
  2024-04-02 11:53       ` Alexander Lobakin
@ 2024-04-02 12:45         ` Eric Dumazet
  2024-04-02 15:53           ` Alexander Lobakin
  0 siblings, 1 reply; 11+ messages in thread
From: Eric Dumazet @ 2024-04-02 12:45 UTC (permalink / raw
  To: Alexander Lobakin
  Cc: Jakub Kicinski, David S. Miller, Paolo Abeni, Dmitry Safonov,
	Heiner Kallweit, nex.sw.ncis.osdt.itp.upstreaming, netdev,
	linux-kernel

On Tue, Apr 2, 2024 at 1:55 PM Alexander Lobakin
<aleksander.lobakin@intel.com> wrote:
>
> From: Jakub Kicinski <kuba@kernel.org>
> Date: Fri, 29 Mar 2024 13:53:44 -0700
>
> > On Fri, 29 Mar 2024 13:18:57 -0700 Jakub Kicinski wrote:
> >>> Sparse:
> >>>
> >>> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: warning: symbol '_res' shadows an earlier one
> >>> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: originally declared here
> >>
> >> I don't see these building with LLVM=1 W=12 C=1
> >> and I really don't like complicating the code because the compiler
> >> is stupid. Can't you solve this with some renames? Add another
>
> It's not the compiler, its warnings are valid actually. Shadowing makes
> it very easy to confuse variables and make bugs...
>
> >> underscore or something?
> >
> > I'm stupid I tried on the test branch which already had your fix..
>
> :D Sometimes it happens.
>
> >
> > This is enough:
> >
> > diff --git a/include/net/netdev_queues.h b/include/net/netdev_queues.h
> > index 1ec408585373..2270fbb99cf7 100644
> > --- a/include/net/netdev_queues.h
> > +++ b/include/net/netdev_queues.h
> > @@ -89,7 +89,7 @@ struct netdev_stat_ops {
> >
> >  #define netif_txq_try_stop(txq, get_desc, start_thrs)                        \
> >       ({                                                              \
> > -             int _res;                                               \
> > +             int __res;                                              \
> >                                                                       \
> >               netif_tx_stop_queue(txq);                               \
> >               /* Producer index and stop bit must be visible          \
> > @@ -101,12 +101,12 @@ struct netdev_stat_ops {
> >               /* We need to check again in a case another             \
> >                * CPU has just made room available.                    \
> >                */                                                     \
> > -             _res = 0;                                               \
> > +             __res = 0;                                              \
> >               if (unlikely(get_desc >= start_thrs)) {                 \
> >                       netif_tx_start_queue(txq);                      \
> > -                     _res = -1;                                      \
> > +                     __res = -1;                                     \
> >               }                                                       \
> > -             _res;                                                   \
> > +             __res;                                                  \
> >       })                                                              \
> >
> >  /**
>
> But what if there's a function which calls one of these functions and
> already has _res or __res or something? I know renaming is enough for
> the warnings I mentioned, but without __UNIQUE_ID() anything can happen
> anytime, so I wanted to fix that once and for all :z
>
> I already saw some macros which have a layer of indirection for
> __UNIQUE_ID(), but previously they didn't and then there were fixes
> which added underscores, renamed variables etc etc...
>

We have hundreds of macros in include/ directory which use local names without
__UNIQUE_ID()

What is the plan ? Hundreds of patches obfuscating them more than they are ?

Can you show us how rb_entry_safe() (random choice) would be rewritten ?

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

* Re: [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse shadow warnings throughout the file
  2024-04-02 12:45         ` Eric Dumazet
@ 2024-04-02 15:53           ` Alexander Lobakin
  2024-04-02 16:48             ` Jakub Kicinski
  0 siblings, 1 reply; 11+ messages in thread
From: Alexander Lobakin @ 2024-04-02 15:53 UTC (permalink / raw
  To: Eric Dumazet
  Cc: Jakub Kicinski, David S. Miller, Paolo Abeni, Dmitry Safonov,
	Heiner Kallweit, nex.sw.ncis.osdt.itp.upstreaming, netdev,
	linux-kernel

From: Eric Dumazet <edumazet@google.com>
Date: Tue, 2 Apr 2024 14:45:07 +0200

> On Tue, Apr 2, 2024 at 1:55 PM Alexander Lobakin
> <aleksander.lobakin@intel.com> wrote:
>>
>> From: Jakub Kicinski <kuba@kernel.org>
>> Date: Fri, 29 Mar 2024 13:53:44 -0700
>>
>>> On Fri, 29 Mar 2024 13:18:57 -0700 Jakub Kicinski wrote:
>>>>> Sparse:
>>>>>
>>>>> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: warning: symbol '_res' shadows an earlier one
>>>>> drivers/net/ethernet/intel/idpf/idpf_txrx.c:1992:16: originally declared here
>>>>
>>>> I don't see these building with LLVM=1 W=12 C=1
>>>> and I really don't like complicating the code because the compiler
>>>> is stupid. Can't you solve this with some renames? Add another
>>
>> It's not the compiler, its warnings are valid actually. Shadowing makes
>> it very easy to confuse variables and make bugs...
>>
>>>> underscore or something?
>>>
>>> I'm stupid I tried on the test branch which already had your fix..
>>
>> :D Sometimes it happens.
>>
>>>
>>> This is enough:
>>>
>>> diff --git a/include/net/netdev_queues.h b/include/net/netdev_queues.h
>>> index 1ec408585373..2270fbb99cf7 100644
>>> --- a/include/net/netdev_queues.h
>>> +++ b/include/net/netdev_queues.h
>>> @@ -89,7 +89,7 @@ struct netdev_stat_ops {
>>>
>>>  #define netif_txq_try_stop(txq, get_desc, start_thrs)                        \
>>>       ({                                                              \
>>> -             int _res;                                               \
>>> +             int __res;                                              \
>>>                                                                       \
>>>               netif_tx_stop_queue(txq);                               \
>>>               /* Producer index and stop bit must be visible          \
>>> @@ -101,12 +101,12 @@ struct netdev_stat_ops {
>>>               /* We need to check again in a case another             \
>>>                * CPU has just made room available.                    \
>>>                */                                                     \
>>> -             _res = 0;                                               \
>>> +             __res = 0;                                              \
>>>               if (unlikely(get_desc >= start_thrs)) {                 \
>>>                       netif_tx_start_queue(txq);                      \
>>> -                     _res = -1;                                      \
>>> +                     __res = -1;                                     \
>>>               }                                                       \
>>> -             _res;                                                   \
>>> +             __res;                                                  \
>>>       })                                                              \
>>>
>>>  /**
>>
>> But what if there's a function which calls one of these functions and
>> already has _res or __res or something? I know renaming is enough for
>> the warnings I mentioned, but without __UNIQUE_ID() anything can happen
>> anytime, so I wanted to fix that once and for all :z
>>
>> I already saw some macros which have a layer of indirection for
>> __UNIQUE_ID(), but previously they didn't and then there were fixes
>> which added underscores, renamed variables etc etc...
>>
> 
> We have hundreds of macros in include/ directory which use local names without
> __UNIQUE_ID()

Most of them were added before __UNIQUE_ID() became norm, weren't they?
Lots of them were switched to __UNIQUE_ID() because of issues, weren't they?

> 
> What is the plan ? Hundreds of patches obfuscating them more than they are ?

Only those which flood the console when building with W=12 C=1 to
recheck that my new code is fine.

> 
> Can you show us how rb_entry_safe() (random choice) would be rewritten ?

Is it unique in some way?

#define _rb_entry_safe(ptr, type, member, ____ptr) \
	({ typeof(ptr) ____ptr = (ptr); \
	   ____ptr ? rb_entry(____ptr, type, member) : NULL; \
	})
#define rb_entry_safe(ptr, type, member)		\
	_rb_entry_safe(ptr, type, member,		\
		       __UNIQUE_ID(ptr_)

(@____ptr can be renamed if needed, this one would give the smallest
 code diff)

If you think +1 layer is a terrible obfuscating, look at
<linux/fortify-string.h> :D

Thanks,
Olek

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

* Re: [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse shadow warnings throughout the file
  2024-04-02 15:53           ` Alexander Lobakin
@ 2024-04-02 16:48             ` Jakub Kicinski
  0 siblings, 0 replies; 11+ messages in thread
From: Jakub Kicinski @ 2024-04-02 16:48 UTC (permalink / raw
  To: Alexander Lobakin
  Cc: Eric Dumazet, David S. Miller, Paolo Abeni, Dmitry Safonov,
	Heiner Kallweit, nex.sw.ncis.osdt.itp.upstreaming, netdev,
	linux-kernel

On Tue, 2 Apr 2024 17:53:08 +0200 Alexander Lobakin wrote:
> >> But what if there's a function which calls one of these functions and
> >> already has _res or __res or something? I know renaming is enough for
> >> the warnings I mentioned, but without __UNIQUE_ID() anything can happen
> >> anytime, so I wanted to fix that once and for all :z
> >>
> >> I already saw some macros which have a layer of indirection for
> >> __UNIQUE_ID(), but previously they didn't and then there were fixes
> >> which added underscores, renamed variables etc etc...
> >>  
> > 
> > We have hundreds of macros in include/ directory which use local names without
> > __UNIQUE_ID()  
> 
> Most of them were added before __UNIQUE_ID() became norm, weren't they?
> Lots of them were switched to __UNIQUE_ID() because of issues, weren't they?

Lots of ugly code gets into the kernel. Just look at your patch and
then look at mine.

I understand __UNIQUE_ID() may be useful for libraries or global
macros in the kernel, but within a subsystem, for macros which are
rarely used, we can just patch the macro var names. Sprinkling
__UNIQUE_ID() is in bad taste.

> > What is the plan ? Hundreds of patches obfuscating them more than they are ?  
> 
> Only those which flood the console when building with W=12 C=1 to
> recheck that my new code is fine.

I have never seen this warning be useful in the context of a macro.
Sure if you shadow inside a function that may be pernicious.
But well written macro will not be a problem.
I guess that it may be really hard for the compiler to understand that
something was a macro but perhaps we should either:
 - ignore the warning if the shadowing happens inside a compound
   statement
 - add a declaration attribute to turn the warning off
?

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

end of thread, other threads:[~2024-04-02 16:48 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-29 16:59 [PATCH net-next 0/2] net: fix variable shadowing spam from headers Alexander Lobakin
2024-03-29 16:59 ` [PATCH net-next 1/2] net/tcp: fix -Wshadow / Sparse shadow warnings in tcp_hash_fail() Alexander Lobakin
2024-03-29 17:00 ` [PATCH net-next 2/2] netdev_queues: fix -Wshadow / Sparse shadow warnings throughout the file Alexander Lobakin
2024-03-29 20:18   ` Jakub Kicinski
2024-03-29 20:18     ` Jakub Kicinski
2024-03-29 20:53     ` Jakub Kicinski
2024-03-29 20:53       ` Jakub Kicinski
2024-04-02 11:53       ` Alexander Lobakin
2024-04-02 12:45         ` Eric Dumazet
2024-04-02 15:53           ` Alexander Lobakin
2024-04-02 16:48             ` Jakub Kicinski

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.