Commit c7228317441f ("net: Use a more standard macro for
INET_ADDR_COOKIE") added a __deprecated marker to the cookie name on
32-bit architectures, with the intent that the compiler would flag
uses of the name. However since commit 771c035372a0 ("deprecate the
'__deprecated' attribute warnings entirely and for good"),
__deprecated doesn't do anything and should be avoided.
This patch changes INET_ADDR_COOKIE to declare a dummy typedef (so it
makes checkpatch.pl complain, sorry...) so that any subsequent use of
the cookie's name will in all likelihood break the build. It also
removes the __deprecated marker.
Signed-off-by: Stephen Kitt <[email protected]>
---
include/net/inet_hashtables.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/net/inet_hashtables.h b/include/net/inet_hashtables.h
index ad64ba6a057f..8a1391d82406 100644
--- a/include/net/inet_hashtables.h
+++ b/include/net/inet_hashtables.h
@@ -301,8 +301,9 @@ static inline struct sock *inet_lookup_listener(struct net *net,
((__sk)->sk_bound_dev_if == (__sdif))) && \
net_eq(sock_net(__sk), (__net)))
#else /* 32-bit arch */
+/* Break the build if anything tries to use the cookie's name. */
#define INET_ADDR_COOKIE(__name, __saddr, __daddr) \
- const int __name __deprecated __attribute__((unused))
+ typedef void __name __attribute__((unused))
#define INET_MATCH(__sk, __net, __cookie, __saddr, __daddr, __ports, __dif, __sdif) \
(((__sk)->sk_portpair == (__ports)) && \
--
2.20.1
From: Stephen Kitt <[email protected]>
Date: Tue, 28 Apr 2020 09:52:31 +0200
> This patch changes INET_ADDR_COOKIE to declare a dummy typedef (so it
> makes checkpatch.pl complain, sorry...)
This is trading one problem for another, so in the end doesn't really
move us forward.
On Tue, 28 Apr 2020 14:07:46 -0700 (PDT), David Miller <[email protected]>
wrote:
> From: Stephen Kitt <[email protected]>
> Date: Tue, 28 Apr 2020 09:52:31 +0200
>
> > This patch changes INET_ADDR_COOKIE to declare a dummy typedef (so it
> > makes checkpatch.pl complain, sorry...)
>
> This is trading one problem for another, so in the end doesn't really
> move us forward.
Right, a dummy struct is probably better, I’ll send a v2.
Regards,
Stephen