Re: [PATCH mptcp-net] mptcp: prevent add_addr timer rearm during teardown

[Li Xiasong <lixiasong1@huawei.com>]

Hi Matt, Hi Kalpan,

Thank you for your review and suggestion.

The main reason I have been hesitating to send a v2 is that,
after re-checking the code paths more carefully, I am no longer
sure that the original issue reported by Sashiko can actually
happen in this add_addr timer path.

My current understanding is that both sk_stop_timer_sync() and
sk_shutdown_timer_sync() synchronously stop the timer: if the
callback is running, they wait for it to finish, and if the
callback re-arms the timer before returning, the pending timer
is then deleted before the helper returns.

So for this specific add_addr timer, I do not currently see a
path where teardown completes and a re-armed timer is still
left behind afterward. That is why I have not sent a v2 based
on sk_shutdown_timer_sync() so far.

That said, I think tightening this teardown path could still be
useful for robustness and could help avoid similar issues after
future changes.

On 6/4/2026 3:19 PM, Kalpan Jani wrote:
> Hi Li,
>  
> Great work on this patch series! Your approach of creating sk_shutdown_timer_sync()
> helper is the right pattern.
>  
> I noticed one additional issue: in mptcp_pm_free_anno_list(), the timer_done check
> is unsynchronized:
>  
>     if (!entry->timer_done)  // Data race: no lock protecting this read
>         sk_stop_timer_sync(sk, &entry->add_timer);
>  
> This is a classic data race. Your patch keeps it as-is, but I think we should
> also fix it by removing this check entirely and always calling timer_shutdown_sync().
>  
> Would you be open to adding this improvement to your patch? The benefit:
> - Eliminates the data race
> - Simplifies the code (unconditional shutdown)
> - timer_shutdown_sync() is idempotent anyway
>  

Yes, I think this would be a good direction if timer_done can
be removed safely.

I agree that it would avoid the unsynchronized timer_done check
and simplify the teardown path.

Before removing timer_done, I would like to better understand
the original scenario for which it was introduced.

Matt, if I am understanding it correctly, timer_done was added
to avoid the case where the socket reference held by the timer
becomes the last one, and then sock_put() from the timer
callback triggers socket destruction, which in turn reaches
sk_stop_timer_sync() for the same timer.

If that understanding is correct, my concern is that removing
timer_done without addressing that original case might
re-introduce the self-wait issue during teardown from the timer
callback path.

So overall, I agree with Kalpan's suggestion if timer_done is
indeed no longer needed for that last-reference case. I would
just like to clarify that point first before sending a new
version.

> I'd be happy to:
> 1. Test the updated patch
> 2. Help refine the implementation
> 3. Co-author if you'd like
>  
> What do you think?
>  

Thanks a lot for the offer, I really appreciate it.

Thanks,
Li Xiasong