Hi, Matt On 5/17/2026 1:50 PM, Matthieu Baerts wrote: > Hello, > > On 15/05/2026 06:27, Matthieu Baerts (NGI0) wrote: >> From: Li Xiasong <[email protected]> >> >> When TCP option space is insufficient (e.g., when sending ADD_ADDR with an >> IPv6 address and port while tcp_timestamps is enabled), the original code >> jumped to out_unlock without clearing the addr_signal flag. This caused >> mptcp_pm_add_timer to keep rescheduling indefinitely, not sending ADD_ADDR, >> preventing subsequent addresses in the endpoint list from being announced. > > (...) > >> diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c >> index 3c152bf66cd5..3e770c7407e1 100644 >> --- a/net/mptcp/pm.c >> +++ b/net/mptcp/pm.c > > (...) > >> @@ -414,8 +420,12 @@ mptcp_pm_del_add_timer(struct mptcp_sock *msk, >> /* Note: entry might have been removed by another thread. >> * We hold rcu_read_lock() to ensure it is not freed under us. >> */ >> - if (stop_timer) >> - sk_stop_timer_sync(sk, &entry->add_timer); > FYI, sashiko found a pre-existing issue here, but I guess that's not > blocking this series. > > https://sashiko.dev/#/patchset/20260515-net-mptcp-misc-fixes-7-1-rc4-v2-0-701e96419f2f%40kernel.org > > @Li: just to know what I do with this pre-existing issue, do you plan to > look at it? > > Just in case, I just opened: > > https://github.com/multipath-tcp/mptcp_net-next/issues/623 >
Thanks for the heads-up. I’ll take a look at #623 separately and follow up there. Best regards, Li Xiasong
