From: kuniyu@google.com
To: Eric Dumazet <edumazet@kernel.org>
Cc: "David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Neal Cardwell <ncardwell@google.com>,
Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, Qiliang Yuan <odys.yuan@gmail.com>
Subject: Re: [PATCH net] tcp: tcp_metrics: use the socket netns, not the dst device netns
Date: Sat, 17 Oct 2026 04:08:41 +0000 [thread overview]
Message-ID: <atL0mHavBRoo27tr@google.com> (raw)
In-Reply-To: <20261016084802.2725187-1-edumazet@kernel.org>
On Fri, 16 Oct 2026 10:48:02 +0200, Eric Dumazet wrote:
> tcp_get_metrics(), __tcp_get_metrics_req() and tcpm_new() look up and
> create metrics entries in the netns of the cached dst device rather than
> in the netns of the socket.
>
> These usually match, but not after the device has been moved to another
> netns or unregistered: a socket can keep a stale dst in sk_dst_cache
> until it is checked again, and tcp_update_metrics() reads it with
> __sk_dst_get() without any dst_check(). Once dst_dev_put() has run, the
> dst device is blackhole_netdev and the entry is created in init_net.
> Before that, for instance for routes through nexthop objects whose
> cached dsts are released from a nested RCU callback, it is the netns the
> device has just been moved to.
>
> A TCP socket of netns A that enters TIME_WAIT in that window then
> creates or updates an entry carrying A's addresses and RTT in another
> netns, where TCP_METRICS_CMD_GET can dump it and where new connections
> to the same peer inherit those metrics.
>
> The metrics belong to the netns of the socket, so use sock_net() for
> full sockets and request sockets, and pass it to tcpm_new().
>
> Kernel sockets that do not hold a netns reference can still reach
> tcp_time_wait() after tcp_net_metrics_exit_batch() has flushed the
> entries of their dismantling netns, and an entry created then would
> never be flushed and would keep a dangling tcpm_net. Make tcpm_new()
> refuse to create entries when check_net() fails. Its callers are in
> an RCU read-side section, and cleanup_net() waits for a grace period
> between the refcount reaching zero and the flush, so an entry added
> after a successful check is always seen by the flush.
>
> Fixes: 51c5d0c4b169 ("tcp: Maintain dynamic metrics in local cache.")
> Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
prev parent reply other threads:[~2026-10-17 4:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 8:48 [PATCH net] tcp: tcp_metrics: use the socket netns, not the dst device netns Eric Dumazet
2026-10-16 8:53 ` netdev-bot+sinfo
2026-10-16 9:11 ` Eric Dumazet
2026-10-16 15:55 ` Neal Cardwell
2026-10-16 16:08 ` Eric Dumazet
2026-10-17 4:08 ` kuniyu [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=atL0mHavBRoo27tr@google.com \
--to=kuniyu@google.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=odys.yuan@gmail.com \
--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.