Re: [PATCH net v2 0/8] mptcp: misc fixes for v7.2-rc6

[Matthieu Baerts <matttbe@kernel.org>]

Hello,

Regarding the "funny" Clashiko's (long) comments [1]:

TL;DR: I think this series can be applied as it is.

On 03/08/2026 18:16, Matthieu Baerts (NGI0) wrote:
> Here are various unrelated fixes:
> 
> - Patches 1-3: harden incoming MPTCP suboptions parsing by rejecting
>   non-combinable ones. Patch 3 removes unreachable code after patch 2
>   added here for consistency, and to reduce comments from AI reviews.
>   Fixes for v5.6.

- Patch 1: indeed, there is another existing issue to fix. This will be
done in a follow-up patch.

- Patch 2:
 - Yes, combining some options is wrong, even if the RFC doesn't
explicitly mention that, and if there is space. As I explained in the
commit message when this happens, it is likely a buggy or bad behaviour
from the other peer, no need to try to get things working in this case.
 - No I'm not going to mention all possible wrong combinations, it is
enough to explain the pattern and give the list of allowed combined options.
 - Also, no need to insist about the same existing issue...

- Patch 3: wow, no comments :-O

> - Patch 4: fix a data race in the ADD_ADDR timer callback. A fix for
>   v5.13.

- An existing issue to fix, this will be done in a follow-up patch.

> - Patch 5: correctly catch data corruption during the MPTCP join
>   selftest by marking tests as failed, instead of only printing a
>   warning. A fix for v5.18.
> 
> - Patch 6: fix a leak with the userspace ADD_ADDR list in case of race
>   condition during teardown. A fix for v5.19.

I don't think the mentioned existing race is possible: I would need a
reproducer. Also, I don't think the commit message needs to be even
longer, and no need to change the error for the userspace daemon: it
will get the notification about the close, and it depends on how the
userspace daemon handle that, possibly in an async way, so no need to
get something better for this race case on the close side.

Also, no need to add a BUILD_BUG_ON(). This can be dealt next time a
flag is added (or on next).

> - Patch 7: deal with MPTFO with a valid token, but no data in the SYN. A
>   fix for v6.2.

Same answer as on v1 (despite the new comment in the commit message):
getting a more precise comment there doesn't have a lot of value: "doing
TFO" means having data in the SYN there. If the comment is modified,
that will certainly cause troubles during the backports.

> - Patch 8: reclaim forward-allocated memory in case of error on the
>   receive side. A fix for v6.19.
Existing issue that will be addressed by the "mptcp: out-of-order queue
pruning" series.

[1]
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-0-b8f496d71664%40kernel.org

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