On Wed, Sep 04, 2024 at 03:43:03PM +0200, Matthieu Baerts wrote: > 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 Ok, I think I've got this all right for 6.6.y now, if not, please let me know. thanks, greg k-h
