mbox series

[net,0/7] mptcp: locking cleanup & misc. fixes

Message ID 20240208-upstream-net-20240202-locking-cleanup-misc-v1-0-f75cc5b97e5a@kernel.org (mailing list archive)
Headers show
Series mptcp: locking cleanup & misc. fixes | expand

Message

Matthieu Baerts Feb. 8, 2024, 6:03 p.m. UTC
Patches 1-4 are fixes for issues found by Paolo while working on adding
TCP_NOTSENT_LOWAT support. The latter will need to track more states
under the msk data lock. Since the locking msk locking schema is already
quite complex, do a long awaited clean-up step by moving several
confusing lockless initialization under the relevant locks. Note that it
is unlikely a real race could happen even prior to such patches as the
MPTCP-level state machine implicitly ensures proper serialization of the
write accesses, even lacking explicit lock. But still, simplification is
welcome and this will help for the maintenance. This can be backported
up to v5.6.

Patch 5 is a fix for the userspace PM, not to add new local address
entries if the address is already in the list. This behaviour can be
seen since v5.19.

Patch 6 fixes an issue when Fastopen is used. The issue can happen since
v6.2. A previous fix has already been applied, but not taking care of
all cases according to syzbot.

Patch 7 updates Geliang's email address in the MAINTAINERS file.

Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Geliang Tang (2):
      mptcp: check addrs list in userspace_pm_get_local_id
      MAINTAINERS: update Geliang's email address

Paolo Abeni (5):
      mptcp: drop the push_pending field
      mptcp: fix rcv space initialization
      mptcp: fix more tx path fields initialization
      mptcp: corner case locking for rx path fields initialization
      mptcp: really cope with fastopen race

 .mailmap                 |  9 +++---
 MAINTAINERS              |  2 +-
 net/mptcp/fastopen.c     |  6 ++--
 net/mptcp/options.c      |  9 +++---
 net/mptcp/pm_userspace.c | 13 ++++++++-
 net/mptcp/protocol.c     | 31 +++++++++++----------
 net/mptcp/protocol.h     | 16 ++++++-----
 net/mptcp/subflow.c      | 71 ++++++++++++++++++++++++++++++------------------
 8 files changed, 95 insertions(+), 62 deletions(-)
---
base-commit: 335bac1daae3fd9070d0f9f34d7d7ba708729256
change-id: 20240202-upstream-net-20240202-locking-cleanup-misc-5f2ee79d8356

Best regards,

Comments

patchwork-bot+netdevbpf@kernel.org Feb. 12, 2024, 10:10 a.m. UTC | #1
Hello:

This series was applied to netdev/net.git (main)
by David S. Miller <davem@davemloft.net>:

On Thu, 08 Feb 2024 19:03:48 +0100 you wrote:
> Patches 1-4 are fixes for issues found by Paolo while working on adding
> TCP_NOTSENT_LOWAT support. The latter will need to track more states
> under the msk data lock. Since the locking msk locking schema is already
> quite complex, do a long awaited clean-up step by moving several
> confusing lockless initialization under the relevant locks. Note that it
> is unlikely a real race could happen even prior to such patches as the
> MPTCP-level state machine implicitly ensures proper serialization of the
> write accesses, even lacking explicit lock. But still, simplification is
> welcome and this will help for the maintenance. This can be backported
> up to v5.6.
> 
> [...]

Here is the summary with links:
  - [net,1/7] mptcp: drop the push_pending field
    https://git.kernel.org/netdev/net/c/bdd70eb68913
  - [net,2/7] mptcp: fix rcv space initialization
    https://git.kernel.org/netdev/net/c/013e3179dbd2
  - [net,3/7] mptcp: fix more tx path fields initialization
    https://git.kernel.org/netdev/net/c/3f83d8a77eee
  - [net,4/7] mptcp: corner case locking for rx path fields initialization
    https://git.kernel.org/netdev/net/c/e4a0fa47e816
  - [net,5/7] mptcp: check addrs list in userspace_pm_get_local_id
    https://git.kernel.org/netdev/net/c/f012d796a6de
  - [net,6/7] mptcp: really cope with fastopen race
    https://git.kernel.org/netdev/net/c/337cebbd850f
  - [net,7/7] MAINTAINERS: update Geliang's email address
    https://git.kernel.org/netdev/net/c/68990d006d42

You are awesome, thank you!