Re: [PATCH 16/16 net-next v2] ipv4: make CONFIG_IPV4 boolean

[netdev-bot+sashiko@kernel.org]

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

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

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 commit message says this patch lets users "build
  IPv6-only".
- [Low] This patch makes CONFIG_IPV4 user-selectable, but two IPv4-only
  options in net/ipv4/Kconfig still have no `depends on IPV4`:…

--

ipv4: make CONFIG_IPV4 boolean

This patch turns CONFIG_IPV4 from a hidden def_bool y into a prompt that
users can see. The prompt appears when IPV6 is enabled and defaults to
INET. The goal is to allow an IPv6-only kernel build.

> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
> index 51bf05d9770c5..c7d36cfa4a1d2 100644
> --- a/net/ipv4/Kconfig
> +++ b/net/ipv4/Kconfig
> @@ -3,7 +3,15 @@
>  # IP configuration
>  #
>  config IPV4
> -	def_bool y
> +	bool "The IPv4 protocol" if IPV6
> +	default INET
> +	help
> +	  Support for IP version 4 (IPv4).
> +
> +	  Disabling this option compiles the kernel networking stack without
> +	  IPv4 support, resulting in a IPv6-only system.

[Severity: Medium]
Is "IPv6-only system" an accurate description of what IPV4=n produces?

This prompt makes IPV4=n reachable, so every existing "depends on IPV4"
in the tree now takes effect. Several of those also gate IPv6 features.

Both netfilter menus depend on IPV4:

net/netfilter/Kconfig:
menu "Core Netfilter Configuration"
	depends on INET && IPV4 && NETFILTER

net/ipv6/netfilter/Kconfig:
	depends on INET && IPV6 && NETFILTER && IPV4

That means there is no ip6tables and no nftables for IPv6.

XFRM depends on IPV4 as well:

net/xfrm/Kconfig:
config XFRM
	bool
	depends on INET && IPV4

INET6_AH, INET6_ESP, INET6_IPCOMP, IPV6_MIP6 and IPV6_VTI in
net/ipv6/Kconfig are gated the same way, so IPv6 IPsec is lost.

SYN_COOKIES has "depends on IPV4", and net/ipv6/Makefile builds the IPv6
side only under that symbol:

ipv6-$(CONFIG_SYN_COOKIES) += syncookies.o

As a result, IPv6 TCP listeners have no SYN cookies. TCP_MD5SIG and
TCP_AO are also gated on IPV4, even though tcp_ipv6.c and ipv6/tcp_ao.o
implement them for IPv6.

Other options that drop out:

  - IPV6_MROUTE, IPV6_TUNNEL, IPV6_GRE, IPV6_SIT and ILA
  - the SEG6, RPL and IOAM6 lwtunnels
  - the drivers BONDING, WIREGUARD, OVPN, IPVLAN, VXLAN, GENEVE, BAREUDP,
    GTP, PFCP, AMT, NET_VRF and NETDEVSIM

A user who follows this help text gets an IPv6 host with no packet
filter, no SYN cookies, no IPsec and no multicast routing. With
olddefconfig, these options are also dropped without any message.

Could the help text and changelog mention these limitations? Or should
the IPv6 side of these dependencies be relaxed before the prompt is
exposed?

> +
> +	  If unsure, say Y.
>  
>  config IP_MULTICAST
>  	bool "IP: multicasting"

[Severity: Low]
Now that IPV4 is optional, should IP_MULTICAST get a "depends on IPV4"?
The same question applies to NET_IPGRE_DEMUX further down in this file.

Similar options such as NET_IPGRE, IP_MROUTE, IP_PNP, SYN_COOKIES and
TCP_MD5SIG already have that dependency. With IPV4=n, these two prompts
are still offered, and existing configs keep them enabled.

For IP_MULTICAST, this looks like it can break the s390 build. QETH uses
IP_MULTICAST as its only IPv4 gate:

drivers/s390/net/Kconfig:
config QETH
	def_tristate y
	prompt "Gigabit Ethernet device support"
	depends on CCW && NETDEVICES && IP_MULTICAST && QDIO && ETHERNET

QETH_L3 builds qeth_l3_main.c, which calls devinet.c helpers without any
condition:

drivers/s390/net/qeth_l3_main.c:qeth_l3_register_notifiers() {
	...
	rc = register_inetaddr_notifier(&qeth_l3_ip_notifier);
	if (rc)
		return rc;
	...
}

qeth_l3_unregister_notifiers() calls unregister_inetaddr_notifier() the
same way.

devinet.o is only built under obj-$(CONFIG_IPV4) in net/ipv4/Makefile,
and include/linux/inetdevice.h has no stubs for these functions.

Would a config with IPV6=y, IPV4=n, IP_MULTICAST=y and QETH_L3 enabled
fail to link, with undefined references to register_inetaddr_notifier()
and unregister_inetaddr_notifier()?

NET_IPGRE_DEMUX still builds gre.o, and gre_init() in
net/ipv4/gre_demux.c still registers an IPv4 protocol handler:

	if (inet_add_protocol(&net_gre_protocol, IPPROTO_GRE) < 0) {

No IPv4 receive path exists in this configuration. The in-tree users of
this module, NET_IPGRE and IPV6_GRE, both require IPV4, so the module
does nothing.

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