From: Ido Schimmel <idosch@nvidia.com>
To: Daehyeon Ko <4ncienth@gmail.com>
Cc: David Ahern <dsahern@kernel.org>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Hannes Frederic Sowa <hannes@stressinduktion.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v4 4/4] ipv6: do not restart DAD for a dead ifaddr
Date: Thu, 15 Oct 2026 17:32:48 +0300 [thread overview]
Message-ID: <20261015143248.GD1794897@shredder> (raw)
In-Reply-To: <20261015050651.1841557-5-4ncienth@gmail.com>
On Thu, Oct 15, 2026 at 02:06:51PM +0900, Daehyeon Ko wrote:
> addrconf_dad_failure() can create a stable-privacy replacement without
> RTNL. After ipv6_add_addr() publishes it, addrconf_ifdown() can mark the
> new ifaddr DEAD, clear its route, and unlink it before the recovery path
> takes ifp2->lock.
>
> The recovery path then unconditionally changes the state back to PREDAD
> and queues delayed DAD work. The MTU teardown path can leave IF_READY
> set. For an optimistic address, addrconf_dad_begin() can consequently
> pass the cleared NULL route to ip6_ins_rt().
>
> This follow-on was found by source review and was not separately
> triggered at runtime.
>
> The new ifaddr is already initialized in PREDAD. Under ifp2->lock, record
> the retry and queue DAD only if teardown has not changed the state to
> DEAD. If teardown wins after this check, the work observes DEAD and exits
> without reviving the address.
>
> This complements the existing lock_errdad check that preserves the original
> ifaddr's DEAD state after the same function reacquires its lock.
>
> Fixes: 5f40ef77adb2 ("ipv6: do retries on stable privacy addresses")
> Cc: stable@vger.kernel.org
> Reported-by: Sashiko <netdev-bot+sashiko@kernel.org>
> Closes: https://lore.kernel.org/r/179161099408.434549.14449036924552933828@kernel.org
> Link: https://lore.kernel.org/r/20260513025509.3776405-1-lilinmao@kylinos.cn
> Assisted-by: LLM
> Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
Same comment as on the previous patch. My diff [1] was simpler and your
commit message admits that it's fine:
"If teardown wins after this check, the work observes DEAD and exits
without reviving the address"
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
[1] https://lore.kernel.org/netdev/20261012151316.GA798355@shredder/
prev parent reply other threads:[~2026-10-15 14:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 5:06 [PATCH net v4 0/4] ipv6: fix address publication races with addrconf_ifdown Daehyeon Ko
2026-10-15 5:06 ` [PATCH net v4 1/4] ipv6: remove ifaddr from hash during ifdown list cleanup Daehyeon Ko
2026-10-15 14:31 ` Ido Schimmel
2026-10-15 5:06 ` [PATCH net v4 2/4] ipv6: serialize address publication with device teardown Daehyeon Ko
2026-10-15 14:32 ` Ido Schimmel
2026-10-15 5:06 ` [PATCH net v4 3/4] ipv6: initialize temporary ifaddr before publication Daehyeon Ko
2026-10-15 14:32 ` Ido Schimmel
2026-10-15 5:06 ` [PATCH net v4 4/4] ipv6: do not restart DAD for a dead ifaddr Daehyeon Ko
2026-10-15 14:32 ` Ido Schimmel [this message]
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=20261015143248.GD1794897@shredder \
--to=idosch@nvidia.com \
--cc=4ncienth@gmail.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@kernel.org \
--cc=hannes@stressinduktion.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/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.