Re: [PATCH net v3] ipv4: bump rt_genid when a relevant devconf value changes through netlink

[Fernando Fernandez Mancera <fmancera@suse.de>]

On 3/4/26 3:38 AM, Jakub Kicinski wrote:
> On Mon,  2 Mar 2026 14:08:57 +0100 Fernando Fernandez Mancera wrote:
>> +			switch (nla_type(a)) {
>> +			case IPV4_DEVCONF_FORWARDING:
>> +				if (nla_get_u32(a))
>> +					netif_disable_lro(dev);
> 
> why not dev_disable_lro()??

dev_disable_lro() takes netdev_lock_ops() but when handling IFLA_AF_SPEC 
at net/core/rtnetlink.c:3320 we are already holding netdev lock ops. So 
we need to call netif_disable_lro() instead.

> 
>> +				fallthrough;
>> +			case IPV4_DEVCONF_NOXFRM:
>> +			case IPV4_DEVCONF_NOPOLICY:
>> +			case IPV4_DEVCONF_PROMOTE_SECONDARIES:
>> +			case IPV4_DEVCONF_ROUTE_LOCALNET:
>> +			case IPV4_DEVCONF_DROP_UNICAST_IN_L2_MULTICAST:
>> +				flush_cache = true;
>> +				break;
>> +			default:
>> +				break;
>> +			}
>> +		}
>> +		if (flush_cache)
>> +			rt_cache_flush(net);
>>   	}
> 
> Looking closer at this I'm struggling to connect this to
> devinet_conf_proc(). The attrs you're snooping here are completely different!?
> Logic for when rt_cache_flush() happens is different.
> 

So I was planning to to handle inet_netconf_notify_devconf() calls in a 
follow-up patch to net-next because it might require some more changes 
and also the missing notification shouldn't be net tree material IMHO.

This is handling ipv4_doint_and_flush() which is used by 
DEVINET_SYSCTL_FLUSHING_ENTRY() macro. But now that you mention it, 
BC_FORWARDING and ACCEPT_LOCAL are part of devinet_conf_proc() while 
they probably could go to ipv4_doint_and_flush().

In addition, I guess we should flush the cache only if the value 
changed. I will add that bit too.

P.S: there is also dead code in devinet_conf_proc() as `i == 
IPV4_DEVCONF_ROUTE_LOCALNET - 1` won't never evaluate as true.

Thanks,
Fernando.

> inet_netconf_notify_devconf() is missing even after the patch.