Re: [PATCH 6.6.y] selftests: mptcp: join: cannot rm sf if closed

[Matthieu Baerts <matttbe@kernel.org>]

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@kernel.org

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