This is the new iteration of "mptcp: strict local address ID selection."
should hopefully fix the last self-test failure.

patch 1/3 is a somewhat related cleanup (to be squashed into existing
patch)
patch 2/3 should address the self-test failure
patch 3/3 avoids RFC breakage reported into the previous iteration,
leveraging the previois one

Paolo Abeni (3):
  Squash-to: "mptcp: constify a bunch of of helpers"
  mptcp: more careful RM_ADDR generation
  mptcp: strict local address ID selection.

 include/uapi/linux/mptcp.h |  1 +
 net/mptcp/pm_netlink.c     | 44 ++++++++++++-------------
 net/mptcp/protocol.c       |  3 ++
 net/mptcp/protocol.h       |  3 +-
 net/mptcp/subflow.c        | 67 +++++++++++++++++++++++++++++++++-----
 5 files changed, 84 insertions(+), 34 deletions(-)

-- 
2.34.1

Hi Paolo,

On 10/02/2022 19:49, Paolo Abeni wrote:
> This is the new iteration of "mptcp: strict local address ID selection."
> should hopefully fix the last self-test failure.

Thank you for this v3!

I don't know if there is a link but the CI seems to take longer than
usual with these 3 patches.

With a debug kernel config, it even reached the timeout of 55min I set
to start the VM and run all tests:

- KVM Validation: debug:
  - Critical: Global Timeout ❌:
  - Task: https://cirrus-ci.com/task/6256933542821888
  - Summary:
https://api.cirrus-ci.com/v1/artifact/task/6256933542821888/summary/summary.txt

So I restarted it and I didn't reach the timeout:

- KVM Validation: debug:
  - Unstable: 1 failed test(s): selftest_mptcp_connect 🔴:
  - Task: https://cirrus-ci.com/task/5212186606829568
  - Summary:
https://api.cirrus-ci.com/v1/artifact/task/5212186606829568/summary/summary.txt

Still taking longer than usual I think. But that's hard to be sure about
that with these public CI as we don't control where it is executed and
which other tasks are ran in parallel.
Do you observe the same on your side?


BTW, you can see that on this last build, it detected an issue with
mptcp_connect.sh. It didn't detect that with the previous job. That's
probably not related to your modifications. I just noticed it is not the
first time we got the issue (I didn't see it due to the other issues):

- https://cirrus-ci.com/task/6348125144088576
- https://cirrus-ci.com/task/6565756707012608
- https://cirrus-ci.com/task/5501584690905088
- https://cirrus-ci.com/task/6734301743022080
- https://cirrus-ci.com/task/6064315366113280
- etc.

I'm going to create a new issue for that.

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

On Fri, 2022-02-11 at 11:33 +0100, Matthieu Baerts wrote:
> Hi Paolo,
> 
> On 10/02/2022 19:49, Paolo Abeni wrote:
> > This is the new iteration of "mptcp: strict local address ID selection."
> > should hopefully fix the last self-test failure.
> 
> Thank you for this v3!
> 
> I don't know if there is a link but the CI seems to take longer than
> usual with these 3 patches.
> 
> With a debug kernel config, it even reached the timeout of 55min I set
> to start the VM and run all tests:
> 
> - KVM Validation: debug:
>   - Critical: Global Timeout ❌:
>   - Task: https://cirrus-ci.com/task/6256933542821888
>   - Summary:
> https://api.cirrus-ci.com/v1/artifact/task/6256933542821888/summary/summary.txt
> 
> So I restarted it and I didn't reach the timeout:
> 
> - KVM Validation: debug:
>   - Unstable: 1 failed test(s): selftest_mptcp_connect 🔴:
>   - Task: https://cirrus-ci.com/task/5212186606829568
>   - Summary:
> https://api.cirrus-ci.com/v1/artifact/task/5212186606829568/summary/summary.txt
> 
> Still taking longer than usual I think. But that's hard to be sure about
> that with these public CI as we don't control where it is executed and
> which other tasks are ran in parallel.
> Do you observe the same on your side?

Uhmmm... I did not look closely to the running time. Nothing in the
patch should change it significantly. The successful run for v2 took
1h10':

https://cirrus-ci.com/task/5430100798734336

do you know which is the average runtime for a dbg build? It looks like
> 50' was not uncommon at all... 

I'll try to have a look at the runtime here, but not very soon.

It does look something to be coped by with a suitable timeout.

> BTW, you can see that on this last build, it detected an issue with
> mptcp_connect.sh. It didn't detect that with the previous job. That's
> probably not related to your modifications. I just noticed it is not the
> first time we got the issue (I didn't see it due to the other issues):
> 
> - https://cirrus-ci.com/task/6348125144088576
> - https://cirrus-ci.com/task/6565756707012608
> - https://cirrus-ci.com/task/5501584690905088
> - https://cirrus-ci.com/task/6734301743022080
> - https://cirrus-ci.com/task/6064315366113280
> - etc.
> 
> I'm going to create a new issue for that.
> 
uhm... too much job security hurts ;)

Everyone of such failures is on disconnect test, in the fallback
scenario.

/P