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

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

On 3/14/26 5:16 PM, David Ahern wrote:
> 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?
> 

I don't mind re-routing this net-next and put it together with a 
re-work. I will drop the fixes tag in such case. Is that fine for you Jakub?

Thanks,
Fernando.