Re: [PATCH 01/13 net-next] net: ipv4: introduce CONFIG_IPV4 to decouple the IPv4 stack

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Layer-2 networking features and core drivers incorrectly depend on IPV4, breaking INET=n builds.
--

commit a6e6a467093e978fadc9f73c8f0d22f0bf0ee577
Author: Fernando Fernandez Mancera <fmancera@suse.de>
Subject: net: ipv4: introduce CONFIG_IPV4 to decouple the IPv4 stack

Historically, the IPv4 protocol has been linked to the core INET subsystem.
This patch introduces the CONFIG_IPV4 Kconfig symbol and adds it as a
dependency to multiple networking Kconfig symbols.

> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> index 925ee25d05b47..86b0884968b67 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> @@ -12,6 +12,7 @@ config MLX5_CORE
>  	depends on PTP_1588_CLOCK_OPTIONAL
>  	depends on PCI_HYPERV_INTERFACE || !PCI_HYPERV_INTERFACE
>  	depends on HWMON || !HWMON
> +	depends on IPV4

[Severity: High]
Does adding this dependency on IPV4 mean the Mellanox core driver can no
longer be used for L2/DPDK in IP-less kernels?

The IPV4 symbol is sourced inside the if INET block in net/Kconfig, so it
evaluates to n when INET=n. This seems to prevent selecting MLX5_CORE without
TCP/IP, which causes a regression for valid Layer-2-only kernel configurations.

[ ... ]

> diff --git a/net/bridge/Kconfig b/net/bridge/Kconfig
> index 318715c8fc9bc..421892a031299 100644
> --- a/net/bridge/Kconfig
> +++ b/net/bridge/Kconfig
> @@ -7,6 +7,7 @@ config BRIDGE
>  	tristate "802.1d Ethernet Bridging"
>  	select LLC
>  	select STP
> +	depends on IPV4

[Severity: High]
Is it intentional that Ethernet bridging requires IPV4 here?

Bridging is a Layer-2 feature that does not require INET, but since IPV4 is
evaluated as n in INET=n builds, this completely disables bridging in kernels
configured without TCP/IP, resulting in a configuration regression.

[ ... ]

> diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
> index d6bc295e23a1a..ec485da283730 100644
> --- a/net/mac80211/Kconfig
> +++ b/net/mac80211/Kconfig
> @@ -1,7 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  config MAC80211
>  	tristate "Generic IEEE 802.11 Networking Stack (mac80211)"
> -	depends on CFG80211
> +	depends on CFG80211 && IPV4

[Severity: High]
Does the generic 802.11 stack need to be rendered unavailable if INET=n?

Since it does not require IP, adding the IPV4 dependency seems to cause a
regression for valid Layer-2-only configurations.

[ ... ]

> diff --git a/net/packet/Kconfig b/net/packet/Kconfig
> index 2997382d597c2..00fda9e08cb0b 100644
> --- a/net/packet/Kconfig
> +++ b/net/packet/Kconfig
> @@ -5,6 +5,7 @@
>  
>  config PACKET
>  	tristate "Packet socket"
> +	depends on IPV4

[Severity: High]
Can packet sockets (AF_PACKET) still be used when INET=n?

They provide direct Layer-2 access and are independent of INET, but this
dependency causes a regression by making them unavailable in INET=n builds.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910144914.8025-1-fmancera@suse.de?part=1