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

[David Ahern <dsahern@kernel.org>]

On 3/14/26 10:06 AM, Jakub Kicinski wrote:
> On Fri, 13 Mar 2026 16:13:20 +0100 Fernando Fernandez Mancera wrote:
>>> Also, you are flushing the cache for more values than sysfs does.  
>>
>> I don't think so. The problem is that the handling of sysctl is 
>> scattered in several places.
>>
>> IPV4_DEVCONF_FORWARDING is flushed at devinet_sysctl_forward().
>>
>> IPV4_DEVCONF_NOXFRM, IPV4_DEVCONF_NOPOLICY, 
>> IPV4_DEVCONF_PROMOTE_SECONDARIES, IPV4_DEVCONF_ROUTE_LOCALNET, and 
>> IPV4_DEVCONF_DROP_UNICAST_IN_L2_MULTICAST are flushed at 
>> ipv4_doint_and_flush() used by macro DEVINET_SYSCTL_FLUSHING_ENTRY.
>>
>> Finally, IPV4_DEVCONF_BC_FORWARDING and IPV4_DEVCONF_ACCEPT_LOCAL are 
>> flushed at devinet_conf_proc().
>>
>> Yes, I know, the fact that they are scattered around is quite confusing. 
>> This could be all unified in a single place but that would be too much 
>> for net tree IMHO.
>>
>> Please let me know if I am missing something.
> 
> I think David means that for some knobs procfs only flushes when value
> changes "in one direct", eg
> 
>                 if (i == IPV4_DEVCONF_ACCEPT_LOCAL - 1 ||                       
>                     i == IPV4_DEVCONF_ROUTE_LOCALNET - 1)                       
>                         if ((new_value == 0) && (old_value != 0))               
>                                 rt_cache_flush(net);       
> 
> which means only flush on the 1 -> 0 transition.

logic subtleties like this example is why I was asking about a proper
refactor.

since this bug has been around for years, why worry about a patch for
-net and the back propagation to stable releases that will follow?