Re: [PATCH 11/16 net-next v2] ipv4: disable IPv4-only sysctls when CONFIG_IPV4=n

[netdev-bot+sashiko@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The patch moves the `fib_multipath_hash_seed` entry of
  `ipv4_net_table` (net/ipv4/sysctl_net_ipv4.c:1644-1650) into the new…

--

ipv4: disable IPv4-only sysctls when CONFIG_IPV4=n

This commit moves the IPv4-only entries of ipv4_net_table into a new
IS_ENABLED(CONFIG_IPV4) block, so they are not registered when IPv4
support is compiled out. The handlers and limit variables that are now
only used conditionally are marked __maybe_unused.

> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
> index 0e7fef5973db6..6096e9e4d82d8 100644
> --- a/net/ipv4/sysctl_net_ipv4.c
> +++ b/net/ipv4/sysctl_net_ipv4.c

[ ... ]

> @@ -492,9 +493,9 @@ static void proc_fib_multipath_hash_set_seed(struct net *net, u32 user_seed)
>  	WRITE_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed.mp_seed, new.mp_seed);
>  }
>  
> -static int proc_fib_multipath_hash_seed(const struct ctl_table *table, int write,
> -					void *buffer, size_t *lenp,
> -					loff_t *ppos)
> +static int __maybe_unused
> +proc_fib_multipath_hash_seed(const struct ctl_table *table, int write,
> +			     void *buffer, size_t *lenp, loff_t *ppos)
>  {
>  	struct sysctl_fib_multipath_hash_seed *mphs;
>  	struct net *net = table->data;

[ ... ]

> @@ -1656,6 +1469,196 @@ static const struct ctl_table ipv4_net_table[] = {
>  		.extra1		= SYSCTL_ONE_THOUSAND,
>  		.extra2		= &tcp_rto_max_max,
>  	},
> +#if IS_ENABLED(CONFIG_IPV4)
> +	{
> +		.procname	= "icmp_echo_ignore_all",

[ ... ]

> +#ifdef CONFIG_IP_ROUTE_MULTIPATH
> +	{
> +		.procname	= "fib_multipath_use_neigh",

[ ... ]

> +	{
> +		.procname	= "fib_multipath_hash_seed",
> +		.data		= &init_net,
> +		.maxlen		= sizeof(u32),
> +		.mode		= 0644,
> +		.proc_handler	= proc_fib_multipath_hash_seed,
> +	},
> +#endif

[Severity: Medium]
Is fib_multipath_hash_seed really an IPv4-only sysctl?

The seed is read by the shared helper fib_multipath_hash_from_keys(),
which is gated only by CONFIG_IP_ROUTE_MULTIPATH:

include/net/ip_fib.h:fib_multipath_hash_from_keys() {
    ...
	mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed.mp_seed);
	fib_multipath_hash_construct_key(&hash_key, mp_seed);
    ...
}

The IPv6 datapath calls this helper for every multipath hash, through
rt6_multipath_hash() in net/ipv6/route.c.

net/ipv6/sysctl_net_ipv6.c has its own fib_multipath_hash_policy and
fib_multipath_hash_fields, but it has no seed knob. That makes this entry
the only way to set the seed for either family.
Documentation/networking/ip-sysctl.rst describes it the same way:

    The seed value used when calculating hash for multipath routes. Applies
    to both IPv4 and IPv6 datapath. Only present for kernels built with
    CONFIG_IP_ROUTE_MULTIPATH enabled.

CONFIG_IP_ROUTE_MULTIPATH depends only on IP_ADVANCED_ROUTER, not on
IPV4. After "ipv4: make CONFIG_IPV4 boolean" later in the series,
CONFIG_IPV4 can be disabled when IPV6 is enabled. At the end of the
series this entry is still inside the CONFIG_IPV4 block.

Take a kernel built with CONFIG_IPV4=n, CONFIG_IPV6=y and
CONFIG_IP_ROUTE_MULTIPATH=y. ipv4_sysctl_init_net() still calls
proc_fib_multipath_hash_set_seed(net, 0), so IPv6 ECMP keeps hashing with
the random seed picked at boot. However,
/proc/sys/net/ipv4/fib_multipath_hash_seed no longer exists, so the seed
cannot be set to a fixed value. mlxsw programs its hardware ECMP seed from
user_seed, so it would also always see 0.

Could the fib_multipath_hash_seed entry and proc_fib_multipath_hash_seed()
stay outside the CONFIG_IPV4 block, under CONFIG_IP_ROUTE_MULTIPATH? That
would match how icmp_echo_enable_probe, icmp_msgs_per_sec and
ip_early_demux were left in place. fib_multipath_use_neigh,
fib_multipath_hash_policy and fib_multipath_hash_fields do look IPv4-only
and could stay inside the block.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260928193046.6698-1-fmancera%40suse.de