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>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ