linux-kernel - [PATCH net-next 00/14] mptcp: get rid of msk->subflow

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20230811-upstream-net-next-20230811-mptcp-get-rid-of-msk-subflow-v1-0-36183269ade8@tessares.net>
Date:   Fri, 11 Aug 2023 17:57:13 +0200
From:   Matthieu Baerts <matthieu.baerts@...sares.net>
To:     mptcp@...ts.linux.dev, Mat Martineau <martineau@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        David Ahern <dsahern@...nel.org>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Matthieu Baerts <matthieu.baerts@...sares.net>,
        Kuniyuki Iwashima <kuniyu@...zon.com>
Subject: [PATCH net-next 00/14] mptcp: get rid of msk->subflow

The MPTCP protocol maintains an additional struct socket per connection,
mainly to be able to easily use tcp-level struct socket operations.

This leads to several side effects, beyond the quite unfortunate /
confusing 'subflow' field name:

- active and passive sockets behaviour is inconsistent: only active ones
  have a not NULL msk->subflow, leading to different error handling and
  different error code returned to the user-space in several places.

- active sockets uses an unneeded, larger amount of memory

- passive sockets can't successfully go through accept(), disconnect(),
  accept() sequence, see [1] for more details.

The 13 first patches of this series are from Paolo and address all the
above, finally getting rid of the blamed field:

- The first patch is a minor clean-up.

- In the next 11 patches, msk->subflow usage is systematically removed
  from the MPTCP protocol, replacing it with direct msk->first usage,
  eventually introducing new core helpers when needed.

- The 13th patch finally disposes the field, and it's the only patch in
  the series intended to produce functional changes.

The last and 14th patch is from Kuniyuki and it is not linked to the
previous ones: it is a small clean-up to get rid of an unnecessary check
in mptcp_init_sock().

[1] https://github.com/multipath-tcp/mptcp_net-next/issues/290

Signed-off-by: Matthieu Baerts <matthieu.baerts@...sares.net>
---
Kuniyuki Iwashima (1):
      mptcp: Remove unnecessary test for __mptcp_init_sock()

Paolo Abeni (13):
      mptcp: avoid unneeded mptcp_token_destroy() calls
      mptcp: avoid additional __inet_stream_connect() call
      mptcp: avoid subflow socket usage in mptcp_get_port()
      net: factor out inet{,6}_bind_sk helpers
      mptcp: mptcp: avoid additional indirection in mptcp_bind()
      net: factor out __inet_listen_sk() helper
      mptcp: avoid additional indirection in mptcp_listen()
      mptcp: avoid additional indirection in mptcp_poll()
      mptcp: avoid unneeded indirection in mptcp_stream_accept()
      mptcp: avoid additional indirection in sockopt
      mptcp: avoid ssock usage in mptcp_pm_nl_create_listen_socket()
      mptcp: change the mpc check helper to return a sk
      mptcp: get rid of msk->subflow

 include/net/inet_common.h |   2 +
 include/net/ipv6.h        |   1 +
 net/ipv4/af_inet.c        |  46 ++++++-----
 net/ipv6/af_inet6.c       |  10 ++-
 net/mptcp/pm_netlink.c    |  30 +++----
 net/mptcp/protocol.c      | 194 ++++++++++++++++++++++------------------------
 net/mptcp/protocol.h      |  15 ++--
 net/mptcp/sockopt.c       |  65 ++++++++--------
 8 files changed, 186 insertions(+), 177 deletions(-)
---
base-commit: 80f9ad046052509d0eee9b72e11d0e8ae31b665f
change-id: 20230811-upstream-net-next-20230811-mptcp-get-rid-of-msk-subflow-9ad15cd9cdcb

Best regards,
-- 
Matthieu Baerts <matthieu.baerts@...sares.net>