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

[Greg KH <gregkh@linuxfoundation.org>]

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

Ok, I think I've got this all right for 6.6.y now, if not, please let me
know.

thanks,

greg k-h