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

[Matthieu Baerts <matttbe@kernel.org>]

Hi Tao,

On 31/08/2026 15:00, Tao Cui wrote:
> Hi,
> 
> Thanks for the review. 
> 
> 在 2026/8/31 18:11, sashiko-bot@kernel.org 写道:
>> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>>
>> Pre-existing issues:
>> - [High] Subflows in `join_list` can be leaked due to unsynchronized zeroing of `cb_flags` in `mptcp_disconnect`.
>> - [High] Data race on `pm->reset` and `pm->rm_list_*` fields due to missing `pm->lock` in `mptcp_pm_data_reset()`.
> 
> Both findings are pre-existing issues rather
> than regressions from this series, but I had a look at them:
> 
> For the join_list leak, I agree it is real. When an MP_JOIN is
> processed while the parent socket is being disconnected, the subflow
> is queued in msk->join_list and MPTCP_FLUSH_JOIN_LIST is set under
> the data lock, but mptcp_disconnect() then clears msk->cb_flags with
> a plain write. The flag is lost, mptcp_release_cb() never flushes
> the list, and since mptcp_destroy_common() only iterates conn_list,
> those subflow sockets are leaked. The plain write also drops flags
> that were already pending before the disconnect, so taking the data
> lock around it is not enough. What I have in mind is to keep the
> flush-related bits across the disconnect and let release_sock()
> process the join list as originally intended, or to drain it
> explicitly in the disconnect path, checking the lock nesting
> commented in mptcp_destroy_common().
> 
> For the pm->reset data race, the lasting effect is the counter
> imbalance this series now clamps and traces, and the other fields
> are discarded on a closed socket anyway. The direct fix is to take
> pm->lock around the reset in mptcp_pm_data_reset(), after checking
> the lock ordering on all callers.
> 
> These are two separate bugs with separate Fixes: targets, so I plan
> to submit them as their own series rather than folding them into
> this one.
Thank you! Yes a different series is better.

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