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

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 4 Mar 2026 10:03:37 +0100 Fernando Fernandez Mancera wrote:
> 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.

Makes sense

> >> +				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.

Fair, let's call it out in the commit message, tho

> 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.

Thanks!