[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <74ff659e-45d5-3577-1288-6e3e37dd87c4@cumulusnetworks.com>
Date: Fri, 3 May 2019 16:09:21 +0300
From: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To: David Ahern <dsahern@...nel.org>, davem@...emloft.net
Cc: netdev@...r.kernel.org, David Ahern <dsahern@...il.com>
Subject: Re: [PATCH net-next] ipmr: Do not define MAXVIFS twice
On 03/05/2019 01:23, David Ahern wrote:
> From: David Ahern <dsahern@...il.com>
>
> b70432f7319eb refactored mroute code to make it common between ipv4
> and ipv6. In the process, MAXVIFS got defined a second time: the
> first is in the uapi file linux/mroute.h. A second one was created
> presumably for IPv6 but it is not needed. Remove it and have
> mroute_base.h include the uapi file directly since it is shared.
>
> include/linux/mroute.h can not be included in mroute_base.h because
> it contains a reference to mr_mfc which is defined in mroute_base.h.
>
> Signed-off-by: David Ahern <dsahern@...il.com>
> ---
> include/linux/mroute_base.h | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/include/linux/mroute_base.h b/include/linux/mroute_base.h
> index 34de06b426ef..c5a389f81e91 100644
> --- a/include/linux/mroute_base.h
> +++ b/include/linux/mroute_base.h
> @@ -4,6 +4,7 @@
> #include <linux/netdevice.h>
> #include <linux/rhashtable-types.h>
> #include <linux/spinlock.h>
> +#include <uapi/linux/mroute.h>
> #include <net/net_namespace.h>
> #include <net/sock.h>
> #include <net/fib_notifier.h>
> @@ -90,13 +91,6 @@ static inline int mr_call_vif_notifiers(struct net *net,
> return call_fib_notifiers(net, event_type, &info.info);
> }
>
> -#ifndef MAXVIFS
> -/* This one is nasty; value is defined in uapi using different symbols for
> - * mroute and morute6 but both map into same 32.
> - */
> -#define MAXVIFS 32
> -#endif
> -
> #define VIF_EXISTS(_mrt, _idx) (!!((_mrt)->vif_table[_idx].dev))
>
> /* mfc_flags:
>
It's in fact a mess, ipv6 defines MAXMIFS (notice the *M*) which must match MAX*V*IFS
due to the MAXVIFS use in ipmr_base for one (possibly other places too).. Maybe this value should be
set on initialization per family in the future because if it gets out of sync between v4 and v6 bad
things will follow. :)
Acked-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Powered by blists - more mailing lists