Re: [PATCH 1/2 net v4] ipv6: addrconf: fix temp address generation after prefix deprecation

[Ido Schimmel <idosch@nvidia.com>]

On Thu, May 14, 2026 at 06:00:13PM +0200, Fernando Fernandez Mancera wrote:
> Hi Ido, yes this looks good but I am afraid of using time_after(). Sure, a
> temporary address should never be older than 2 ~ 7 days. Yet, we allow
> configuring it up to 2147483647 (68~ years). And that might cause problems
> in 32-bit systems.
> 
> I think we either limit this configuration on sysctl directly or we need to
> support this nonsense.. another option would be to move inet6_ifaddr out of
> jiffies which is something that I recently added to my TODO list. But that
> is a bigger change I do not want to bundle with this one.
> 
> I noticed that ipv6_add_addr() do:
> 
> list_add(&ifa->tmp_list, &idev->tempaddr_list);
> 
> Doesn't it mean the first address that matches the base prefix is indeed the
> most recent one? I tried a bit and it seems we can use just the first match
> :)

It's very unlikely that jiffies is going to be a problem given that
these are temporary addresses. A lifetime of months / years defeats the
purpose...

I'm OK with relying on the list order, but lets add a comment in
ipv6_add_addr() just before the address is added to the list.

> In addition, I didn't check with Sashiko but it is likely going to complain
> about a race condition for a RA arriving right after we have spawned an
> address but it has not been added to the tempaddr list. Therefore we would
> have two addresses.. anyway, that race is quite unlikely. I also have
> planned work on that are to reduce the multiple race windows, currently
> there are plenty. I suggest to acknowledge such race condition for now and
> improve the code base for the reported scenario.

One possible solution is to encode the regeneration state in the
regeneration counter of temporary addresses. Currently it's essentially
a boolean. We can have:

0 - Pre-regeneration.
1 - Regeneration in progress.
2 - Regeneration done (might have failed).

And only reset the state if regeneration was already done.

> I propose this small change to your proposed diff, I acknowledge that it is
> a bit fragile tho (maybe a comment at ipv6_add_addr() is worth to avoid
> breaking this accidentally):

Yes, comments where we add to the list and where we derive the newest
address based on the order should make this clear.