All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@nvidia.com>
To: Fernando Fernandez Mancera <fmancera@suse.de>
Cc: netdev@vger.kernel.org, linux-kselftest@vger.kernel.org,
	horms@kernel.org, pabeni@redhat.com, kuba@kernel.org,
	edumazet@google.com, davem@davemloft.net, dsahern@kernel.org,
	"Łukasz Stelmach" <steelman@post.pl>
Subject: Re: [PATCH 1/2 net v3] ipv6: addrconf: fix temp address generation after prefix deprecation
Date: Sun, 10 May 2026 17:55:22 +0300	[thread overview]
Message-ID: <20260510145522.GA98198@shredder> (raw)
In-Reply-To: <20260507132828.3923-1-fmancera@suse.de>

On Thu, May 07, 2026 at 03:28:27PM +0200, Fernando Fernandez Mancera wrote:
> When a router temporarily deprecates an IPv6 prefix (either by sending a
> Router Advertisement with Preferred Lifetime = 0 or by letting the
> lifetime expire) and later restores it, the kernel permanently loses its
> ability to generate temporary privacy addresses (RFC 8981) for that
> prefix.
> 
> This happens because the address worker attempts to generate a
> replacement temporary address when the current one nears expiration. As
> the base prefix is deprecated already, the generation fails after
> marking the temporary address already having spawned a replacement
> (ifp->regen_count++).
> 
> When the router eventually restores the prefix, the temporary address
> becomes active again. However, once it naturally expires, the address
> worker sees this temporary address already tried to generate one and
> skips the regeneration.
> 
> Fix this by verifying that the base prefix has sufficient preferred
> lifetime remaining before attempting to generate a new temporary
> address. In addition, make ipv6_create_tempaddr() return meaningful
> error codes. This way, we can catch if a 0-lft RA arrived just after we
> passed the verification mentioned above. If we don't have sufficient
> preferred lifetime remaining, the worker will keep the next timer as it
> is.

I didn't go through all the Sashiko comments, but at least some of them
seem valid. I wonder if we can simplify this and do the following
instead:

When updating all the temporary addresses (f.e., because we received a
RA), instead of only creating a temporary address if none exist, also
create a temporary address if all the existing ones already regenerated
a temporary address, as otherwise no temporary address will ever be
created. Something like [1]. I didn't run it through Sashiko, but I did
confirm that your test fails without it and passes with it.

[1]
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 5476b6536eb7..3eaa583bb08d 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2597,6 +2597,7 @@ static void manage_tempaddrs(struct inet6_dev *idev,
 {
 	u32 flags;
 	struct inet6_ifaddr *ift;
+	bool all_regen = true;
 
 	read_lock_bh(&idev->lock);
 	/* update all temporary addresses in the list */
@@ -2637,6 +2638,8 @@ static void manage_tempaddrs(struct inet6_dev *idev,
 		ift->tstamp = now;
 		if (prefered_lft > 0)
 			ift->flags &= ~IFA_F_DEPRECATED;
+		if (!ift->regen_count)
+			all_regen = false;
 
 		spin_unlock(&ift->lock);
 		if (!(flags&IFA_F_TENTATIVE))
@@ -2644,12 +2647,14 @@ static void manage_tempaddrs(struct inet6_dev *idev,
 	}
 
 	/* Also create a temporary address if it's enabled but no temporary
-	 * address currently exists.
+	 * address currently exists or if all the temporary addresses already
+	 * regenerated an address.
 	 * However, we get called with valid_lft == 0, prefered_lft == 0, create == false
 	 * as part of cleanup (ie. deleting the mngtmpaddr).
 	 * We don't want that to result in creating a new temporary ip address.
 	 */
-	if (list_empty(&idev->tempaddr_list) && (valid_lft || prefered_lft))
+	if ((list_empty(&idev->tempaddr_list) || all_regen)
+	    && (valid_lft || prefered_lft))
 		create = true;
 
 	if (create && READ_ONCE(idev->cnf.use_tempaddr) > 0) {

  parent reply	other threads:[~2026-05-10 14:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-07 13:28 [PATCH 1/2 net v3] ipv6: addrconf: fix temp address generation after prefix deprecation Fernando Fernandez Mancera
2026-05-07 13:28 ` [PATCH 2/2 net v3] selftests: fib_tests: add temporary IPv6 address renewal test Fernando Fernandez Mancera
2026-05-10 14:55 ` Ido Schimmel [this message]
2026-05-10 15:43   ` [PATCH 1/2 net v3] ipv6: addrconf: fix temp address generation after prefix deprecation Fernando Fernandez Mancera

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260510145522.GA98198@shredder \
    --to=idosch@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=fmancera@suse.de \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=steelman@post.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.