Hi Greg, Sasha, On 03/09/2024 12:18, Matthieu Baerts (NGI0) wrote: > commit e93681afcb96864ec26c3b2ce94008ce93577373 upstream. > > Thanks to the previous commit, the MPTCP subflows are now closed on both > directions even when only the MPTCP path-manager of one peer asks for > their closure. > > In the two tests modified here -- "userspace pm add & remove address" > and "userspace pm create destroy subflow" -- one peer is controlled by > the userspace PM, and the other one by the in-kernel PM. When the > userspace PM sends a RM_ADDR notification, the in-kernel PM will > automatically react by closing all subflows using this address. Now, > thanks to the previous commit, the subflows are properly closed on both > directions, the userspace PM can then no longer closes the same > subflows if they are already closed. Before, it was OK to do that, > because the subflows were still half-opened, still OK to send a RM_ADDR. > > In other words, thanks to the previous commit closing the subflows, an > error will be returned to the userspace if it tries to close a subflow > that has already been closed. So no need to run this command, which mean > that the linked counters will then not be incremented. > > These tests are then no longer sending both a RM_ADDR, then closing the > linked subflow just after. The test with the userspace PM on the server > side is now removing one subflow linked to one address, then sending > a RM_ADDR for another address. The test with the userspace PM on the > client side is now only removing the subflow that was previously > created. FYI, Sasha has recently queued this patch to v6.6, with a bunch of dependences. I'm OK with that, no need to take this version here where I resolved the conflicts not to take the dependences. But then, please also queue the 2 patches that are needed for new dependences that have been added: https://lore.kernel.org/20240904133755.67974-4-matttbe@xxxxxxxxxx Cheers, Matt -- Sponsored by the NGI0 Core fund.
