Re: [PATCH mptcp-next 2/2] mptcp: pm: skip extra_subflows accounting on disconnected msk

[Matthieu Baerts <matttbe@kernel.org>]

Hi Tao Cui,

On 31/08/2026 11:32, Tao Cui wrote:
> From: Tao Cui <cuitao@kylinos.cn>
> 
> The WARN_ON_ONCE() guards added to the extra_subflows decrement sites
> turn out to be reachable:
> 
> mptcp_pm_data_reset() zeroes the counter with only the msk socket lock
> held, while an MP_JOIN subflow can still sit in msk->join_list, its
> reference already accounted by mptcp_pm_allow_new_subflow() under
> pm->lock. If the socket gets disconnected(AF_UNSPEC) in that window,
> mptcp_pm_data_reset() zeroes the counter, and the join list is flushed
> later at release_sock() time: the leftover subflow then reaches
> mptcp_pm_subflow_check_next() (or __mptcp_pm_close_subflow() for
> kernel PM sockets) with the counter already at 0, firing the warning.
> On panic_on_warn kernels this is a remotely triggerable panic, which
> is worse than the silent wrap the guards replaced.
> 
> Skip the PM accounting when the msk is already in TCP_CLOSE: in the
> scenario above the state is set before the counters are cleared, and
> once the msk is closed the accounting is not relevant anymore. Keep a
> clamp and a rate-limited pr_warn() on the decrement sites instead,
> to leave a trace of any imbalance we would still not know about.
> 
> Fixes: e99c1ca89071 ("mptcp: pm: add WARN_ON_ONCE guards on extra_subflows underflow")
> Link: https://github.com/multipath-tcp/mptcp_net-next/issues/629

This patch looks good to me, but could you please use the "Closes" tag
for the last patch of the series closing this ticket, please?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.