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.
