Re: [PATCH net 1/5] mptcp: avoid combining some incoming suboptions
Jakub Kicinski <[email protected]> Thu, 30 Jul 2026 13:27:05 -0700
| Newsgroups | dev.linux.lists.mptcp,org.kernel.vger.linux-kernel,org.kernel.vger.netdev,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 30 Jul 2026 10:14:53 +0200 Matthieu Baerts wrote: > On 30/07/2026 02:23, Jakub Kicinski wrote: > > On Tue, 28 Jul 2026 19:11:57 +0200 Matthieu Baerts (NGI0) wrote: > >> Some MPTCP suboptions are mutually exclusive according to the RFC8684, > >> but also because in different places, the code doesn't expect some > >> combinations to be present. That's specially true for suboptions that > >> would be present twice, but with different attributes. > > > > Looks like Clashiko has much to say about this patch. > > Could you check? > > Sure, I will check that. > > Do you think Clashiko could look at patches from the MPTCP ML as well? > Because the (deprecated?) AI review tool we use didn't find anything: > > https://netdev-ai.bots.linux.dev/ai-review.html?id=d1d1ff69-0f15-4812-ad16-e4f6f2df9f6b > > Or maybe that's because the model is different, and this can be easily > fixed? Or maybe the prompts are different too? > > I'm asking, mainly because once patches have been accepted in our tree, > it can be hard to have the original author fixing them. Not to block > other patches too long, I often have to fix them, so I would prefer to > get the same review tools (if possible) to prevent that :) Sorry about that, I know it's annoying. Not the best time TBH. I'm modifying our instances very actively, I don't want to have to worry about the extra surface of integrations. Hopefully things converge soon and we can switch you over and kill that old service we had completely.