summaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/task-analyzer.py
diff options
context:
space:
mode:
authorJakub Kicinski <kuba@kernel.org>2025-11-12 19:17:00 -0800
committerJakub Kicinski <kuba@kernel.org>2025-11-14 17:44:47 -0800
commitc7dc5b5228822d2389e6e441f10169e460bcc67a (patch)
tree974f0755b3280168d3368e8409a6efac7f844807 /tools/perf/scripts/python/task-analyzer.py
parentdf58ee7d8faf353ebf5d4703c35fcf3e578e9b1b (diff)
downloadlinux-c7dc5b5228822d2389e6e441f10169e460bcc67a.tar.gz
linux-c7dc5b5228822d2389e6e441f10169e460bcc67a.zip
ipv6: clean up routes when manually removing address with a lifetime
When an IPv6 address with a finite lifetime (configured with valid_lft and preferred_lft) is manually deleted, the kernel does not clean up the associated prefix route. This results in orphaned routes (marked "proto kernel") remaining in the routing table even after their corresponding address has been deleted. This is particularly problematic on networks using combination of SLAAC and bridges. 1. Machine comes up and performs RA on eth0. 2. User creates a bridge - does an ip -6 addr flush dev eth0; - adds the eth0 under the bridge. 3. SLAAC happens on br0. Even tho the address has "moved" to br0 there will still be a route pointing to eth0, but eth0 is not usable for IP any more. Reviewed-by: David Ahern <dsahern@kernel.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20251113031700.3736285-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/task-analyzer.py')
0 files changed, 0 insertions, 0 deletions