mbox series

[net-next,0/8] mptcp: small improvements, fix and clean-ups

Message ID 20240510-upstream-net-next-20240509-misc-improvements-v1-0-4f25579e62ba@kernel.org (mailing list archive)
Headers show
Series mptcp: small improvements, fix and clean-ups | expand

Message

Matthieu Baerts May 10, 2024, 11:18 a.m. UTC
This series contain mostly unrelated patches:

- The two first patches can be seen as "fixes". They are part of this
  series for -next because it looks like the last batch of fixes for
  v6.9 has already been sent. These fixes are not urgent, so they can
  wait if an unlikely v6.9-rc8 is published. About the two patches:
    - Patch 1 fixes getsockopt(SO_KEEPALIVE) support on MPTCP sockets
    - Patch 2 makes sure the full TCP keep-alive feature is supported,
      not just SO_KEEPALIVE.

- Patch 3 is a small optimisation when getsockopt(MPTCP_INFO) is used
  without buffer, just to check if MPTCP is still being used: no
  fallback to TCP.

- Patch 4 adds net.mptcp.available_schedulers sysctl knob to list packet
  schedulers, similar to net.ipv4.tcp_available_congestion_control.

- Patch 5 and 6 fix CheckPatch warnings: "prefer strscpy over strcpy"
  and "else is not generally useful after a break or return".

- Patch 7 and 8 remove and add header includes to avoid unused ones, and
  add missing ones to be self-contained.

Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Gregory Detal (1):
      mptcp: add net.mptcp.available_schedulers

Matthieu Baerts (NGI0) (7):
      mptcp: SO_KEEPALIVE: fix getsockopt support
      mptcp: fix full TCP keep-alive support
      mptcp: sockopt: info: stop early if no buffer
      mptcp: prefer strscpy over strcpy
      mptcp: remove unnecessary else statements
      mptcp: move mptcp_pm_gen.h's include
      mptcp: include inet_common in mib.h

 include/net/mptcp.h      |  3 +++
 net/mptcp/ctrl.c         | 29 +++++++++++++++++++--
 net/mptcp/mib.h          |  2 ++
 net/mptcp/pm_netlink.c   |  1 +
 net/mptcp/pm_userspace.c |  1 +
 net/mptcp/protocol.c     |  5 ++--
 net/mptcp/protocol.h     |  6 +++--
 net/mptcp/sched.c        | 22 ++++++++++++++++
 net/mptcp/sockopt.c      | 66 +++++++++++++++++++++++++++++++++++++++++++++---
 net/mptcp/subflow.c      | 32 ++++++++++++-----------
 10 files changed, 143 insertions(+), 24 deletions(-)
---
base-commit: 383eed2de529287337d9153a5084d4291a7c69f2
change-id: 20240509-upstream-net-next-20240509-misc-improvements-84b3489136f3

Best regards,

Comments

Jakub Kicinski May 13, 2024, 11:06 p.m. UTC | #1
On Fri, 10 May 2024 13:18:30 +0200 Matthieu Baerts (NGI0) wrote:
> This series contain mostly unrelated patches:
> 
> - The two first patches can be seen as "fixes". They are part of this
>   series for -next because it looks like the last batch of fixes for
>   v6.9 has already been sent. These fixes are not urgent, so they can
>   wait if an unlikely v6.9-rc8 is published. About the two patches:
>     - Patch 1 fixes getsockopt(SO_KEEPALIVE) support on MPTCP sockets
>     - Patch 2 makes sure the full TCP keep-alive feature is supported,
>       not just SO_KEEPALIVE.
> 
> - Patch 3 is a small optimisation when getsockopt(MPTCP_INFO) is used
>   without buffer, just to check if MPTCP is still being used: no
>   fallback to TCP.
> 
> - Patch 4 adds net.mptcp.available_schedulers sysctl knob to list packet
>   schedulers, similar to net.ipv4.tcp_available_congestion_control.
> 
> - Patch 5 and 6 fix CheckPatch warnings: "prefer strscpy over strcpy"
>   and "else is not generally useful after a break or return".
> 
> - Patch 7 and 8 remove and add header includes to avoid unused ones, and
>   add missing ones to be self-contained.

Seems to conflict with:
https://lore.kernel.org/all/20240509-upstream-net-next-20240509-mptcp-tcp_is_mptcp-v1-1-f846df999202@kernel.org/
Mat Martineau May 14, 2024, 12:24 a.m. UTC | #2
On Mon, 13 May 2024, Jakub Kicinski wrote:

> On Fri, 10 May 2024 13:18:30 +0200 Matthieu Baerts (NGI0) wrote:
>> This series contain mostly unrelated patches:
>>
>> - The two first patches can be seen as "fixes". They are part of this
>>   series for -next because it looks like the last batch of fixes for
>>   v6.9 has already been sent. These fixes are not urgent, so they can
>>   wait if an unlikely v6.9-rc8 is published. About the two patches:
>>     - Patch 1 fixes getsockopt(SO_KEEPALIVE) support on MPTCP sockets
>>     - Patch 2 makes sure the full TCP keep-alive feature is supported,
>>       not just SO_KEEPALIVE.
>>
>> - Patch 3 is a small optimisation when getsockopt(MPTCP_INFO) is used
>>   without buffer, just to check if MPTCP is still being used: no
>>   fallback to TCP.
>>
>> - Patch 4 adds net.mptcp.available_schedulers sysctl knob to list packet
>>   schedulers, similar to net.ipv4.tcp_available_congestion_control.
>>
>> - Patch 5 and 6 fix CheckPatch warnings: "prefer strscpy over strcpy"
>>   and "else is not generally useful after a break or return".
>>
>> - Patch 7 and 8 remove and add header includes to avoid unused ones, and
>>   add missing ones to be self-contained.
>
> Seems to conflict with:
> https://lore.kernel.org/all/20240509-upstream-net-next-20240509-mptcp-tcp_is_mptcp-v1-1-f846df999202@kernel.org/

Hi Jakub -

The conflict here is purely in the diff context, patch 2 of this series 
and "tcp: socket option to check for MPTCP fallback to TCP" add cases to 
the same switch statement and have a couple of unmodified lines between 
their additions.

"git am -3" handles it cleanly in this case, if you have time and 
inclination for a second attempt. But I realize you're working through a 
backlog and net-next is now closed, so that time might not be available. 
We'll try again when net-next reopens if needed.


Thanks,
Mat
Jakub Kicinski May 14, 2024, 12:29 a.m. UTC | #3
On Mon, 13 May 2024 17:24:08 -0700 (PDT) Mat Martineau wrote:
> The conflict here is purely in the diff context, patch 2 of this series 
> and "tcp: socket option to check for MPTCP fallback to TCP" add cases to 
> the same switch statement and have a couple of unmodified lines between 
> their additions.
> 
> "git am -3" handles it cleanly in this case, if you have time and 
> inclination for a second attempt. But I realize you're working through a 
> backlog and net-next is now closed, so that time might not be available. 
> We'll try again when net-next reopens if needed.

Your -3 must be more powerful somehow, or my scripts are broken because
it isn't enough on my end.

If you can do a quick resend there's still a chance. The patches look
quite simple.
Mat Martineau May 14, 2024, 12:33 a.m. UTC | #4
On Mon, 13 May 2024, Jakub Kicinski wrote:

> On Mon, 13 May 2024 17:24:08 -0700 (PDT) Mat Martineau wrote:
>> The conflict here is purely in the diff context, patch 2 of this series
>> and "tcp: socket option to check for MPTCP fallback to TCP" add cases to
>> the same switch statement and have a couple of unmodified lines between
>> their additions.
>>
>> "git am -3" handles it cleanly in this case, if you have time and
>> inclination for a second attempt. But I realize you're working through a
>> backlog and net-next is now closed, so that time might not be available.
>> We'll try again when net-next reopens if needed.
>
> Your -3 must be more powerful somehow, or my scripts are broken because
> it isn't enough on my end.
>
> If you can do a quick resend there's still a chance. The patches look
> quite simple.


Thanks Jakub! Spinning a quick v2 right now.


- Mat
Matthieu Baerts May 14, 2024, 8:06 a.m. UTC | #5
Hi Mat, Jakub,

On 14/05/2024 02:33, Mat Martineau wrote:
> On Mon, 13 May 2024, Jakub Kicinski wrote:
> 
>> On Mon, 13 May 2024 17:24:08 -0700 (PDT) Mat Martineau wrote:
>>> The conflict here is purely in the diff context, patch 2 of this series
>>> and "tcp: socket option to check for MPTCP fallback to TCP" add cases to
>>> the same switch statement and have a couple of unmodified lines between
>>> their additions.
>>>
>>> "git am -3" handles it cleanly in this case, if you have time and
>>> inclination for a second attempt. But I realize you're working through a
>>> backlog and net-next is now closed, so that time might not be available.
>>> We'll try again when net-next reopens if needed.
>>
>> Your -3 must be more powerful somehow, or my scripts are broken because
>> it isn't enough on my end.
>>
>> If you can do a quick resend there's still a chance. The patches look
>> quite simple.
> 
> 
> Thanks Jakub! Spinning a quick v2 right now.

Thank you for having sent a v2, and for having applied them!

I'm sorry about the conflicts: I moved the code around on purpose to
avoid them, but it looks like it was not enough. Like Mat, I didn't have
these conflicts locally when I tested before sending the patches. I will
check if there is something I can do to have the same error as the one
you had, to prevent such issues next time.

Cheers,
Matt