[PATCH 1/3 net-next v4] ipv4: centralize devconf sysctl handling

[PATCH 1/3 net-next v4] ipv4: centralize devconf sysctl handling

[Fernando Fernandez Mancera]

The logic for handling IPv4 devconf sysctls is scattered. Notification
and cache flushes are managed in devinet_conf_proc(), while a separate
ipv4_doint_and_flush() function and DEVINET_SYSCTL_FLUSHING_ENTRY macro
is used for properties that solely require a cache flush.

This patch refactors the sysctl handling by introducing a centralized
helper, devinet_conf_post_set(). This new function evaluates the changed
attribute and handles all necessary operations like triggering netlink
notifications. It returns a boolean indicating whether a routing cache
flush is required.

Note that the boolean is necessary as this function will be re-used for
netlink IPv4 devconf handling where the cache flushing must wait until
all the attributes have been processed.

Finally, this is introducing a small change in behavior for
IPV4_DEVCONF_ROUTE_LOCALNET. As commit d0daebc3d622 ("ipv4: Add
interface option to enable routing of 127.0.0.0/8") intended, the cache
flush should only be performed when ROUTE_LOCALNET changes from 1 to 0.
Unfortunately, this was not true because while implementing it the
DEVINET_SYSCTL_FLUSHING_ENTRY was used for the attribute, making the
code related to it on devinet_conf_proc() dead.

IPV4_DEVCONF_FORWARDING is still being handled separately as it requires
more operations.

Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
v2: no changes
v3: no changes
v4: no changes
---
 net/ipv4/devinet.c | 127 ++++++++++++++++++++++++---------------------
 1 file changed, 68 insertions(+), 59 deletions(-)

diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 58fe7cb69545..8300516fb38f 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -2128,6 +2128,46 @@ static int inet_validate_link_af(const struct net_device *dev,
 	return 0;
 }
 
+static bool devinet_conf_post_set(struct net *net, struct ipv4_devconf *cnf,
+				  int attr, int new, int old, int ifindex)
+{
+	if (new == old)
+		return false;
+
+	switch (attr) {
+	case IPV4_DEVCONF_ROUTE_LOCALNET:
+	case IPV4_DEVCONF_ACCEPT_LOCAL:
+		if (new == 0)
+			return true;
+		break;
+	case IPV4_DEVCONF_NOXFRM:
+	case IPV4_DEVCONF_NOPOLICY:
+	case IPV4_DEVCONF_PROMOTE_SECONDARIES:
+	case IPV4_DEVCONF_DROP_UNICAST_IN_L2_MULTICAST:
+	case IPV4_DEVCONF_BC_FORWARDING:
+		return true;
+	case IPV4_DEVCONF_RP_FILTER:
+		inet_netconf_notify_devconf(net, RTM_NEWNETCONF,
+					    NETCONFA_RP_FILTER,
+					    ifindex, cnf);
+		break;
+	case IPV4_DEVCONF_PROXY_ARP:
+		inet_netconf_notify_devconf(net, RTM_NEWNETCONF,
+					    NETCONFA_PROXY_NEIGH,
+					    ifindex, cnf);
+		break;
+	case IPV4_DEVCONF_IGNORE_ROUTES_WITH_LINKDOWN:
+		inet_netconf_notify_devconf(net, RTM_NEWNETCONF,
+					    NETCONFA_IGNORE_ROUTES_WITH_LINKDOWN,
+					    ifindex, cnf);
+		break;
+	default:
+		break;
+	}
+
+	return false;
+}
+
 static int inet_set_link_af(struct net_device *dev, const struct nlattr *nla,
 			    struct netlink_ext_ack *extack)
 {
@@ -2509,44 +2549,31 @@ static int devinet_conf_proc(const struct ctl_table *ctl, int write,
 
 	if (write) {
 		struct ipv4_devconf *cnf = ctl->extra1;
-		struct net *net = ctl->extra2;
 		int i = (int *)ctl->data - cnf->data;
+		struct net *net = ctl->extra2;
 		int ifindex;
 
-		set_bit(i, cnf->state);
-
-		if (cnf == net->ipv4.devconf_dflt)
-			devinet_copy_dflt_conf(net, i);
-		if (i == IPV4_DEVCONF_ACCEPT_LOCAL - 1 ||
-		    i == IPV4_DEVCONF_ROUTE_LOCALNET - 1)
-			if ((new_value == 0) && (old_value != 0))
-				rt_cache_flush(net);
+		/* These attributes are bypassing the tracking state,
+		 * for the rest track the state and propagate the changes
+		 * to default config
+		 */
+		switch (i + 1) {
+		case IPV4_DEVCONF_NOXFRM:
+		case IPV4_DEVCONF_NOPOLICY:
+		case IPV4_DEVCONF_PROMOTE_SECONDARIES:
+		case IPV4_DEVCONF_DROP_UNICAST_IN_L2_MULTICAST:
+			break;
+		default:
+			set_bit(i, cnf->state);
+			if (cnf == net->ipv4.devconf_dflt)
+				devinet_copy_dflt_conf(net, i);
+			break;
+		}
 
-		if (i == IPV4_DEVCONF_BC_FORWARDING - 1 &&
-		    new_value != old_value)
+		ifindex = devinet_conf_ifindex(net, cnf);
+		if (devinet_conf_post_set(net, cnf, i + 1, new_value,
+					  old_value, ifindex))
 			rt_cache_flush(net);
-
-		if (i == IPV4_DEVCONF_RP_FILTER - 1 &&
-		    new_value != old_value) {
-			ifindex = devinet_conf_ifindex(net, cnf);
-			inet_netconf_notify_devconf(net, RTM_NEWNETCONF,
-						    NETCONFA_RP_FILTER,
-						    ifindex, cnf);
-		}
-		if (i == IPV4_DEVCONF_PROXY_ARP - 1 &&
-		    new_value != old_value) {
-			ifindex = devinet_conf_ifindex(net, cnf);
-			inet_netconf_notify_devconf(net, RTM_NEWNETCONF,
-						    NETCONFA_PROXY_NEIGH,
-						    ifindex, cnf);
-		}
-		if (i == IPV4_DEVCONF_IGNORE_ROUTES_WITH_LINKDOWN - 1 &&
-		    new_value != old_value) {
-			ifindex = devinet_conf_ifindex(net, cnf);
-			inet_netconf_notify_devconf(net, RTM_NEWNETCONF,
-						    NETCONFA_IGNORE_ROUTES_WITH_LINKDOWN,
-						    ifindex, cnf);
-		}
 	}
 
 	return ret;
@@ -2599,20 +2626,6 @@ static int devinet_sysctl_forward(const struct ctl_table *ctl, int write,
 	return ret;
 }
 
-static int ipv4_doint_and_flush(const struct ctl_table *ctl, int write,
-				void *buffer, size_t *lenp, loff_t *ppos)
-{
-	int *valp = ctl->data;
-	int val = *valp;
-	int ret = proc_dointvec(ctl, write, buffer, lenp, ppos);
-	struct net *net = ctl->extra2;
-
-	if (write && *valp != val)
-		rt_cache_flush(net);
-
-	return ret;
-}
-
 #define DEVINET_SYSCTL_ENTRY(attr, name, mval, proc) \
 	{ \
 		.procname	= name, \
@@ -2633,9 +2646,6 @@ static int ipv4_doint_and_flush(const struct ctl_table *ctl, int write,
 #define DEVINET_SYSCTL_COMPLEX_ENTRY(attr, name, proc) \
 	DEVINET_SYSCTL_ENTRY(attr, name, 0644, proc)
 
-#define DEVINET_SYSCTL_FLUSHING_ENTRY(attr, name) \
-	DEVINET_SYSCTL_COMPLEX_ENTRY(attr, name, ipv4_doint_and_flush)
-
 static struct devinet_sysctl_table {
 	struct ctl_table_header *sysctl_header;
 	struct ctl_table devinet_vars[IPV4_DEVCONF_MAX];
@@ -2678,15 +2688,14 @@ static struct devinet_sysctl_table {
 					"ignore_routes_with_linkdown"),
 		DEVINET_SYSCTL_RW_ENTRY(DROP_GRATUITOUS_ARP,
 					"drop_gratuitous_arp"),
-
-		DEVINET_SYSCTL_FLUSHING_ENTRY(NOXFRM, "disable_xfrm"),
-		DEVINET_SYSCTL_FLUSHING_ENTRY(NOPOLICY, "disable_policy"),
-		DEVINET_SYSCTL_FLUSHING_ENTRY(PROMOTE_SECONDARIES,
-					      "promote_secondaries"),
-		DEVINET_SYSCTL_FLUSHING_ENTRY(ROUTE_LOCALNET,
-					      "route_localnet"),
-		DEVINET_SYSCTL_FLUSHING_ENTRY(DROP_UNICAST_IN_L2_MULTICAST,
-					      "drop_unicast_in_l2_multicast"),
+		DEVINET_SYSCTL_RW_ENTRY(NOXFRM, "disable_xfrm"),
+		DEVINET_SYSCTL_RW_ENTRY(NOPOLICY, "disable_policy"),
+		DEVINET_SYSCTL_RW_ENTRY(PROMOTE_SECONDARIES,
+					"promote_secondaries"),
+		DEVINET_SYSCTL_RW_ENTRY(ROUTE_LOCALNET,
+					"route_localnet"),
+		DEVINET_SYSCTL_RW_ENTRY(DROP_UNICAST_IN_L2_MULTICAST,
+					"drop_unicast_in_l2_multicast"),
 	},
 };
 
-- 
2.53.0

[PATCH 2/3 net-next v4] ipv4: handle devconf post-set actions on netlink updates

[Fernando Fernandez Mancera]

When IPv4 device configuration parameters are updated via netlink, the
kernel currently only updates the value. This bypasses several
post-modification actions that occur when these same parameters are
updated via sysctl, such as flushing the routing cache or emitting
RTM_NEWNETCONF notifications.

This patch addresses the inconsistency by calling the
devinet_conf_post_set() helper inside inet_set_link_af(). If a flush is
required, we defer it until the netlink attribute parsing loop
completes.

This ensures consistent behavior and side-effects for devconf changes,
regardless of whether they are initiated via sysctl or netlink.

Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
v2: handled forwarding notification and disabling LRO
v3: no changes
v4: no changes
---
 net/ipv4/devinet.c | 29 +++++++++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 8300516fb38f..a35b72662e43 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -2161,6 +2161,20 @@ static bool devinet_conf_post_set(struct net *net, struct ipv4_devconf *cnf,
 					    NETCONFA_IGNORE_ROUTES_WITH_LINKDOWN,
 					    ifindex, cnf);
 		break;
+	case IPV4_DEVCONF_FORWARDING:
+		if (new == 1) {
+			/* it is safe to use container_of() because forwarding case
+			 * is only used by the netlink path
+			 */
+			struct in_device *idev = container_of(cnf, struct in_device, cnf);
+
+			netif_disable_lro(idev->dev);
+		}
+
+		inet_netconf_notify_devconf(net, RTM_NEWNETCONF,
+					    NETCONFA_FORWARDING,
+					    ifindex, cnf);
+		return true;
 	default:
 		break;
 	}
@@ -2173,6 +2187,8 @@ static int inet_set_link_af(struct net_device *dev, const struct nlattr *nla,
 {
 	struct in_device *in_dev = __in_dev_get_rtnl(dev);
 	struct nlattr *a, *tb[IFLA_INET_MAX+1];
+	struct net *net = dev_net(dev);
+	bool flush_cache = false;
 	int rem;
 
 	if (!in_dev)
@@ -2182,8 +2198,17 @@ static int inet_set_link_af(struct net_device *dev, const struct nlattr *nla,
 		return -EINVAL;
 
 	if (tb[IFLA_INET_CONF]) {
-		nla_for_each_nested(a, tb[IFLA_INET_CONF], rem)
-			ipv4_devconf_set(in_dev, nla_type(a), nla_get_u32(a));
+		nla_for_each_nested(a, tb[IFLA_INET_CONF], rem) {
+			int old_value = ipv4_devconf_get(in_dev, nla_type(a));
+			int new_value = nla_get_u32(a);
+
+			ipv4_devconf_set(in_dev, nla_type(a), new_value);
+			if (devinet_conf_post_set(net, &in_dev->cnf, nla_type(a), new_value,
+						  old_value, dev->ifindex))
+				flush_cache = true;
+		}
+		if (flush_cache)
+			rt_cache_flush(net);
 	}
 
 	return 0;
-- 
2.53.0

Re: [PATCH 2/3 net-next v4] ipv4: handle devconf post-set actions on netlink updates

[Jakub Kicinski]

On Sun, 10 May 2026 10:15:27 +0200 Fernando Fernandez Mancera wrote:
> -		nla_for_each_nested(a, tb[IFLA_INET_CONF], rem)
> -			ipv4_devconf_set(in_dev, nla_type(a), nla_get_u32(a));
> +		nla_for_each_nested(a, tb[IFLA_INET_CONF], rem) {
> +			int old_value = ipv4_devconf_get(in_dev, nla_type(a));
> +			int new_value = nla_get_u32(a);

Hm, what checks if nla_type(a) is in range?

Re: [PATCH 2/3 net-next v4] ipv4: handle devconf post-set actions on netlink updates

[Fernando Fernandez Mancera]

On 5/14/26 4:30 AM, Jakub Kicinski wrote:
> On Sun, 10 May 2026 10:15:27 +0200 Fernando Fernandez Mancera wrote:
>> -		nla_for_each_nested(a, tb[IFLA_INET_CONF], rem)
>> -			ipv4_devconf_set(in_dev, nla_type(a), nla_get_u32(a));
>> +		nla_for_each_nested(a, tb[IFLA_INET_CONF], rem) {
>> +			int old_value = ipv4_devconf_get(in_dev, nla_type(a));
>> +			int new_value = nla_get_u32(a);
> 
> Hm, what checks if nla_type(a) is in range?

That is handled at inet_validate_link_af(), see:

	if (tb[IFLA_INET_CONF]) {
		err = nla_parse_nested(nested_tb, IPV4_DEVCONF_MAX,
				       tb[IFLA_INET_CONF], inet_devconf_policy,
				       extack);

		if (err < 0)
			return err;
	}

(sorry if the formatting is messed up)

Thanks!
Fernando.

[PATCH 3/3 net-next v4] selftests: net: add test for IPv4 devconf netlink notifications

[Fernando Fernandez Mancera]

Introduce a new test, `ipv4_devconf_notify`, to verify that the kernel
sends the appropriate netlink notifications when IPv4 devconf parameters
are modified.

Since YNL currently has a bug where it declares an array of u32 values
instead of the nested attributes expected by the kernel for devconf set
operations, a temporary hack (`patched_add_attr`) is included to
pack the netlink attributes correctly.

Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
v3: added this patch to the series as requested by Paolo.
v4: fixed lint warnings, some of them cannot be fixed as they are
related to the YNL hack.
---
 tools/testing/selftests/net/rtnetlink.py | 74 ++++++++++++++++++++++--
 1 file changed, 70 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/net/rtnetlink.py b/tools/testing/selftests/net/rtnetlink.py
index e9ad5e88da97..c4136e73b6d0 100755
--- a/tools/testing/selftests/net/rtnetlink.py
+++ b/tools/testing/selftests/net/rtnetlink.py
@@ -1,17 +1,22 @@
 #!/usr/bin/env python3
 # SPDX-License-Identifier: GPL-2.0
 
-from lib.py import ksft_exit, ksft_run, ksft_ge, RtnlAddrFamily
 import socket
+import struct
+import time
+import types
+from lib.py import bkg, ip, ksft_exit, ksft_run, ksft_ge, ksft_true
+from lib.py import NetNS, NetNSEnter, RtnlAddrFamily, RtnlFamily
 
 IPV4_ALL_HOSTS_MULTICAST = b'\xe0\x00\x00\x01'
 
-def dump_mcaddr_check(rtnl: RtnlAddrFamily) -> None:
+def dump_mcaddr_check() -> None:
     """
     Verify that at least one interface has the IPv4 all-hosts multicast address.
     At least the loopback interface should have this address.
     """
 
+    rtnl = RtnlAddrFamily()
     addresses = rtnl.getmulticast({"ifa-family": socket.AF_INET}, dump=True)
 
     all_host_multicasts = [
@@ -21,9 +26,70 @@ def dump_mcaddr_check(rtnl: RtnlAddrFamily) -> None:
     ksft_ge(len(all_host_multicasts), 1,
             "No interface found with the IPv4 all-hosts multicast address")
 
+def ipv4_devconf_notify() -> None:
+    """
+    Configure an interface and set ipv4-devconf values through netlink
+    to verify that the appropriate netlink notifications are being sent.
+    """
+
+    with NetNS() as ns:
+        with NetNSEnter(str(ns)):
+            rtnl = RtnlFamily()
+
+            ifname = "dummy1"
+            ip(f"link add name {ifname} type dummy", ns=str(ns))
+
+            link_info = ip(f"link show dev {ifname}", ns=str(ns), json=True)
+            ksft_true(bool(link_info), f"Failed to retrieve link info for {ifname}")
+            ifindex = link_info[0]["ifindex"]
+
+            # YNL do not support netconf notifications yet
+            with bkg("ip monitor", ns=str(ns)) as cmd_obj:
+                original_add_attr = rtnl._add_attr
+                time.sleep(0.5)
+
+                # Currently YNL has a bug for applying devconf values,
+                # this hack fixes it. In essence, YNL is declaring an
+                # array of u32 values, while kernel expects a nested attribute
+                # on set operation.
+                def patched_add_attr(self, space, name, value, search_attrs):
+                    if name == 'conf' and value == b"MAGIC_CONF":
+                        fwd_attr = struct.pack("=HHI", 8, 1, 1)
+                        proxy_arp_attr = struct.pack("=HHI", 8, 3, 1)
+                        rp_filter_attr = struct.pack("=HHI", 8, 8, 1)
+                        ignore_routes_attr = struct.pack("=HHI", 8, 29, 1)
+
+                        return struct.pack("=HH", 36, 0x8001) + fwd_attr \
+                                + proxy_arp_attr \
+                                + rp_filter_attr \
+                                + ignore_routes_attr
+
+                    return original_add_attr(space, name, value, search_attrs)
+
+                rtnl._add_attr = types.MethodType(patched_add_attr, rtnl)
+
+                req = {
+                    "ifi-index": ifindex,
+                    "af-spec": {
+                        "inet": {
+                            "conf": b"MAGIC_CONF"
+                        }
+                    }
+                }
+                rtnl.newlink(req)
+                time.sleep(0.5)
+
+    ksft_true(f"inet {ifname} ignore_routes_with_linkdown on" in cmd_obj.stdout,
+              f"No 'ignore_routes_with_linkdown on' notificiation found for interface {ifname}")
+    ksft_true(f"inet {ifname} rp_filter strict" in cmd_obj.stdout,
+              f"No 'rp_filter strict' notificiation found for interface {ifname}")
+    ksft_true(f"inet {ifname} proxy_neigh on" in cmd_obj.stdout,
+              f"No 'proxy_neigh on' notificiation found for interface {ifname}")
+    ksft_true(f"inet {ifname} forwarding on" in cmd_obj.stdout,
+              f"No 'forwarding on' notificiation found for interface {ifname}")
+
 def main() -> None:
-    rtnl = RtnlAddrFamily()
-    ksft_run([dump_mcaddr_check], args=(rtnl, ))
+    ksft_run([dump_mcaddr_check, ipv4_devconf_notify])
     ksft_exit()
 
 if __name__ == "__main__":
-- 
2.53.0

Re: [PATCH 3/3 net-next v4] selftests: net: add test for IPv4 devconf netlink notifications

[Jakub Kicinski]

On Sun, 10 May 2026 10:15:28 +0200 Fernando Fernandez Mancera wrote:
> Introduce a new test, `ipv4_devconf_notify`, to verify that the kernel
> sends the appropriate netlink notifications when IPv4 devconf parameters
> are modified.
> 
> Since YNL currently has a bug where it declares an array of u32 values
> instead of the nested attributes expected by the kernel for devconf set
> operations, a temporary hack (`patched_add_attr`) is included to
> pack the netlink attributes correctly.

Right, YNL doesn't really support the level or weirdness that netconf
requires. Why use YNL? Can't we test this with iproute2?

nit: sashiko found a typo in "notificiation"
-- 
pw-bot: cr

Re: [PATCH 3/3 net-next v4] selftests: net: add test for IPv4 devconf netlink notifications

[Fernando Fernandez Mancera]

On 5/14/26 4:35 AM, Jakub Kicinski wrote:
> On Sun, 10 May 2026 10:15:28 +0200 Fernando Fernandez Mancera wrote:
>> Introduce a new test, `ipv4_devconf_notify`, to verify that the kernel
>> sends the appropriate netlink notifications when IPv4 devconf parameters
>> are modified.
>>
>> Since YNL currently has a bug where it declares an array of u32 values
>> instead of the nested attributes expected by the kernel for devconf set
>> operations, a temporary hack (`patched_add_attr`) is included to
>> pack the netlink attributes correctly.
> 
> Right, YNL doesn't really support the level or weirdness that netconf
> requires. Why use YNL? Can't we test this with iproute2?
> 

No, AFAIU, iproute2 does not expose devconf settings. The main user of 
IFLA_INET_CONF are netlink libraries and other userspace tools that 
heavily rely on netlink operations like NetworkManager, nmstate, nispor, 
rust-netlink..

FWIW, I plan to fix the YNL side of things so we have this fixed 
properly. But I would prefer if this isn't blocked. Another patchset 
introducing IFLA_INET6_CONF support is also coming.. being able to avoid 
sysctl usage is quite useful for these userspace tools.

> nit: sashiko found a typo in "notificiation"

Should I repost for this?

Thanks for the feedback Jakub, I know everyone is quite busy recently. 
So I really appreciate you took the time to look at it.

Thanks,
Fernando.

Re: [PATCH 3/3 net-next v4] selftests: net: add test for IPv4 devconf netlink notifications

[Jakub Kicinski]

On Thu, 14 May 2026 11:42:16 +0200 Fernando Fernandez Mancera wrote:
> On 5/14/26 4:35 AM, Jakub Kicinski wrote:
> > On Sun, 10 May 2026 10:15:28 +0200 Fernando Fernandez Mancera wrote:  
> >> Introduce a new test, `ipv4_devconf_notify`, to verify that the kernel
> >> sends the appropriate netlink notifications when IPv4 devconf parameters
> >> are modified.
> >>
> >> Since YNL currently has a bug where it declares an array of u32 values
> >> instead of the nested attributes expected by the kernel for devconf set
> >> operations, a temporary hack (`patched_add_attr`) is included to
> >> pack the netlink attributes correctly.  
> > 
> > Right, YNL doesn't really support the level or weirdness that netconf
> > requires. Why use YNL? Can't we test this with iproute2?
> 
> No, AFAIU, iproute2 does not expose devconf settings. The main user of 
> IFLA_INET_CONF are netlink libraries and other userspace tools that 
> heavily rely on netlink operations like NetworkManager, nmstate, nispor, 
> rust-netlink..

Isn't this ip netconf ?

> FWIW, I plan to fix the YNL side of things so we have this fixed 
> properly.

If it adds any hacks or new concepts to YNL it's unlikely to 
be accepted :(

> But I would prefer if this isn't blocked. Another patchset 
> introducing IFLA_INET6_CONF support is also coming.. being able to avoid 
> sysctl usage is quite useful for these userspace tools.

Re: [PATCH 3/3 net-next v4] selftests: net: add test for IPv4 devconf netlink notifications

[Fernando Fernandez Mancera]

On 5/15/26 1:24 AM, Jakub Kicinski wrote:
> On Thu, 14 May 2026 11:42:16 +0200 Fernando Fernandez Mancera wrote:
>> On 5/14/26 4:35 AM, Jakub Kicinski wrote:
>>> On Sun, 10 May 2026 10:15:28 +0200 Fernando Fernandez Mancera wrote:
>>>> Introduce a new test, `ipv4_devconf_notify`, to verify that the kernel
>>>> sends the appropriate netlink notifications when IPv4 devconf parameters
>>>> are modified.
>>>>
>>>> Since YNL currently has a bug where it declares an array of u32 values
>>>> instead of the nested attributes expected by the kernel for devconf set
>>>> operations, a temporary hack (`patched_add_attr`) is included to
>>>> pack the netlink attributes correctly.
>>>
>>> Right, YNL doesn't really support the level or weirdness that netconf
>>> requires. Why use YNL? Can't we test this with iproute2?
>>
>> No, AFAIU, iproute2 does not expose devconf settings. The main user of
>> IFLA_INET_CONF are netlink libraries and other userspace tools that
>> heavily rely on netlink operations like NetworkManager, nmstate, nispor,
>> rust-netlink..
> 
> Isn't this ip netconf ?
> 

Oh sorry, I should have clarified it. ip netconf only shows/query them 
but it cannot set them AFAICS.

Usage: ip netconf show [ dev STRING ]

>> FWIW, I plan to fix the YNL side of things so we have this fixed
>> properly.
> 
> If it adds any hacks or new concepts to YNL it's unlikely to
> be accepted :(
> 
>> But I would prefer if this isn't blocked. Another patchset
>> introducing IFLA_INET6_CONF support is also coming.. being able to avoid
>> sysctl usage is quite useful for these userspace tools.
> 

Re: [PATCH 3/3 net-next v4] selftests: net: add test for IPv4 devconf netlink notifications

[Jakub Kicinski]

On Fri, 15 May 2026 10:02:50 +0200 Fernando Fernandez Mancera wrote:
> >> No, AFAIU, iproute2 does not expose devconf settings. The main user of
> >> IFLA_INET_CONF are netlink libraries and other userspace tools that
> >> heavily rely on netlink operations like NetworkManager, nmstate, nispor,
> >> rust-netlink..  
> > 
> > Isn't this ip netconf ?
> >   
> 
> Oh sorry, I should have clarified it. ip netconf only shows/query them 
> but it cannot set them AFAICS.
> 
> Usage: ip netconf show [ dev STRING ]

Oh, fun. anyway, you gotta find a better way. Or just give up on the
selftest, the YNL hack is too ugly to live

Re: [PATCH 3/3 net-next v4] selftests: net: add test for IPv4 devconf netlink notifications

[Fernando Fernandez Mancera]

On 5/16/26 3:16 AM, Jakub Kicinski wrote:
> On Fri, 15 May 2026 10:02:50 +0200 Fernando Fernandez Mancera wrote:
>>>> No, AFAIU, iproute2 does not expose devconf settings. The main user of
>>>> IFLA_INET_CONF are netlink libraries and other userspace tools that
>>>> heavily rely on netlink operations like NetworkManager, nmstate, nispor,
>>>> rust-netlink..
>>>
>>> Isn't this ip netconf ?
>>>    
>>
>> Oh sorry, I should have clarified it. ip netconf only shows/query them
>> but it cannot set them AFAICS.
>>
>> Usage: ip netconf show [ dev STRING ]
> 
> Oh, fun. anyway, you gotta find a better way. Or just give up on the
> selftest, the YNL hack is too ugly to live
> 

Fair, let me see what I can do. Otherwise, Paolo as you requested the 
selftest, would it be acceptable for you to drop it given the situation? 
I looking for alternatives anyway :-)

Thanks!
Fernando.

Re: [PATCH 3/3 net-next v4] selftests: net: add test for IPv4 devconf netlink notifications

[Jakub Kicinski]

On Sat, 16 May 2026 09:02:27 +0200 Fernando Fernandez Mancera wrote:
> >> Oh sorry, I should have clarified it. ip netconf only shows/query them
> >> but it cannot set them AFAICS.
> >>
> >> Usage: ip netconf show [ dev STRING ]  
> > 
> > Oh, fun. anyway, you gotta find a better way. Or just give up on the
> > selftest, the YNL hack is too ugly to live
> >   
> 
> Fair, let me see what I can do. Otherwise, Paolo as you requested the 
> selftest, would it be acceptable for you to drop it given the situation? 
> I looking for alternatives anyway :-)

Maybe extend iproute2 ?

Re: [PATCH 3/3 net-next v4] selftests: net: add test for IPv4 devconf netlink notifications

[Paolo Abeni]

On 5/18/26 11:23 PM, Jakub Kicinski wrote:
> On Sat, 16 May 2026 09:02:27 +0200 Fernando Fernandez Mancera wrote:
>>>> Oh sorry, I should have clarified it. ip netconf only shows/query them
>>>> but it cannot set them AFAICS.
>>>>
>>>> Usage: ip netconf show [ dev STRING ]  
>>>
>>> Oh, fun. anyway, you gotta find a better way. Or just give up on the
>>> selftest, the YNL hack is too ugly to live
>>>   
>>
>> Fair, let me see what I can do. Otherwise, Paolo as you requested the 
>> selftest, would it be acceptable for you to drop it given the situation? 
>> I looking for alternatives anyway :-)
> 
> Maybe extend iproute2 ?

Ideally I think extending iproute2 would be the better solution.
@Fernando: perhaps you could update the self-test accordingly, adding an
explicit check for the iproute subcommand. If `ip netconf set` is not
available skip the test, so that iproute2 patches could land later.

Does the above look feasible?

/P

Re: [PATCH 3/3 net-next v4] selftests: net: add test for IPv4 devconf netlink notifications

[Fernando Fernandez Mancera]

On 5/19/26 9:17 AM, Paolo Abeni wrote:
> On 5/18/26 11:23 PM, Jakub Kicinski wrote:
>> On Sat, 16 May 2026 09:02:27 +0200 Fernando Fernandez Mancera wrote:
>>>>> Oh sorry, I should have clarified it. ip netconf only shows/query them
>>>>> but it cannot set them AFAICS.
>>>>>
>>>>> Usage: ip netconf show [ dev STRING ]
>>>>
>>>> Oh, fun. anyway, you gotta find a better way. Or just give up on the
>>>> selftest, the YNL hack is too ugly to live
>>>>    
>>>
>>> Fair, let me see what I can do. Otherwise, Paolo as you requested the
>>> selftest, would it be acceptable for you to drop it given the situation?
>>> I looking for alternatives anyway :-)
>>
>> Maybe extend iproute2 ?
> 
> Ideally I think extending iproute2 would be the better solution.
> @Fernando: perhaps you could update the self-test accordingly, adding an
> explicit check for the iproute subcommand. If `ip netconf set` is not
> available skip the test, so that iproute2 patches could land later.
> 
> Does the above look feasible?
> 

Yep. I agree. Okay, let's do that :-)

Thanks a lot!

Re: [PATCH 3/3 net-next v4] selftests: net: add test for IPv4 devconf netlink notifications

[Nicolas Dichtel]

Le 19/05/2026 à 09:17, Paolo Abeni a écrit :
> On 5/18/26 11:23 PM, Jakub Kicinski wrote:
>> On Sat, 16 May 2026 09:02:27 +0200 Fernando Fernandez Mancera wrote:
>>>>> Oh sorry, I should have clarified it. ip netconf only shows/query them
>>>>> but it cannot set them AFAICS.
>>>>>
>>>>> Usage: ip netconf show [ dev STRING ]  
>>>>
>>>> Oh, fun. anyway, you gotta find a better way. Or just give up on the
>>>> selftest, the YNL hack is too ugly to live
>>>>   
>>>
>>> Fair, let me see what I can do. Otherwise, Paolo as you requested the 
>>> selftest, would it be acceptable for you to drop it given the situation? 
>>> I looking for alternatives anyway :-)
>>
>> Maybe extend iproute2 ?
> 
> Ideally I think extending iproute2 would be the better solution.
> @Fernando: perhaps you could update the self-test accordingly, adding an
> explicit check for the iproute subcommand. If `ip netconf set` is not
> available skip the test, so that iproute2 patches could land later.
> 
> Does the above look feasible?
FWIW, netconf != devconf.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/ip.h#n156
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/netconf.h

The devconf API exposes all sysctl of an interface via RTM_NEWLINK /
IFLA_AF_SPEC / IFLA_INET_CONF. There is no event when a sysctl changes.
These sysctl can be set via RTM_SETLINK.

The netconf API (RTM_NEWNETCONF) is a notification mechanism used to notify
users when a sysctl changes. It handles sysctl from interfaces but also from the
'all' and the 'default' entries. RTM_GETNETCONF is also supported, but not
RTM_SETNETCONF.

'ip netconf' uses the netconf API.

Regards,
Nicolas

Re: [PATCH 3/3 net-next v4] selftests: net: add test for IPv4 devconf netlink notifications

[Fernando Fernandez Mancera]

On 5/19/26 3:45 PM, Nicolas Dichtel wrote:
> Le 19/05/2026 à 09:17, Paolo Abeni a écrit :
>> On 5/18/26 11:23 PM, Jakub Kicinski wrote:
>>> On Sat, 16 May 2026 09:02:27 +0200 Fernando Fernandez Mancera wrote:
>>>>>> Oh sorry, I should have clarified it. ip netconf only shows/query them
>>>>>> but it cannot set them AFAICS.
>>>>>>
>>>>>> Usage: ip netconf show [ dev STRING ]
>>>>>
>>>>> Oh, fun. anyway, you gotta find a better way. Or just give up on the
>>>>> selftest, the YNL hack is too ugly to live
>>>>>    
>>>>
>>>> Fair, let me see what I can do. Otherwise, Paolo as you requested the
>>>> selftest, would it be acceptable for you to drop it given the situation?
>>>> I looking for alternatives anyway :-)
>>>
>>> Maybe extend iproute2 ?
>>
>> Ideally I think extending iproute2 would be the better solution.
>> @Fernando: perhaps you could update the self-test accordingly, adding an
>> explicit check for the iproute subcommand. If `ip netconf set` is not
>> available skip the test, so that iproute2 patches could land later.
>>
>> Does the above look feasible?
> FWIW, netconf != devconf.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/ip.h#n156
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/netconf.h
> 
> The devconf API exposes all sysctl of an interface via RTM_NEWLINK /
> IFLA_AF_SPEC / IFLA_INET_CONF. There is no event when a sysctl changes.
> These sysctl can be set via RTM_SETLINK.
> 
> The netconf API (RTM_NEWNETCONF) is a notification mechanism used to notify
> users when a sysctl changes. It handles sysctl from interfaces but also from the
> 'all' and the 'default' entries. RTM_GETNETCONF is also supported, but not
> RTM_SETNETCONF.
> 
> 'ip netconf' uses the netconf API.
> 


I think we can reword this to.. "extend iproute2 to support setting 
devconf values"? If the naming or implementation on iproute2 is not 
clear now, we can merge this without the selftest and after the iproute2 
implementation merge the selftest.

> Regards,
> Nicolas
>