[PATCH mptcp-next v5 00/11] Fix socket options used by NVMe over MPTCP

Geliang Tang <[email protected]>
Newsgroups dev.linux.lists.mptcp
Message-ID <[email protected]>
From: Geliang Tang <[email protected]>

NVMe over MPTCP relies on SO_LINGER, SO_PRIORITY, SO_REUSEADDR, TCP_SYNCNT,
TCP_NODELAY, IP_TOS, and SO_BINDTODEVICE. This series contains fixes to
make all of them work correctly, and adds tclass support for it.

v5:
 - Include Gang Yan's TCP_MAXSEG cleanup.
 - Include two v4-mapped addr fixes.
 - Patch 9, set rcv_flowinfo to 0 for v4-mapped addr.
 - Patch 11, use rcv_flowinfo instead of np->tclass.
 - All comments from Sashiko on v4 regarding "CONFIG_IPV6=m" are false
   positives.

v4:
 - patch 1: skip ssk->sk_bound_dev_if = local->ifindex when local->ifindex
   is 0, so __mptcp_subflow_connect() doesn't overwrite the inherited
   SO_BINDTODEVICE binding.
 - patch 4: assign tcp_sock_set_syncnt()'s return to ret so an invalid
   TCP_SYNCNT is propagated, not silently dropped.
 - patch 6: skip IPV6_TCLASS setsockopt/getsockopt paths on AF_INET
   sockets/subflows (inet6_sk is NULL there).
 - patch 7: treat IPv4-mapped IPv6 as AF_INET for the TOS/tclass path.
 - patch 9: gate ip6_sock_set_tclass() behind sk_family == AF_INET6 and
   IS_ENABLED(CONFIG_IPV6) to avoid IPv4 NULL-deref and link failure when
   CONFIG_IPV6 is off.
 - patch 10: gate tclass on sk_family, skip IPv6 branch for IPv4-mapped
   connections, wrap IPv6 in CONFIG_IPV6.
 - https://patchwork.kernel.org/project/mptcp/cover/[email protected]/

v3:
 - include tclass patches.
 - I also included three NVMe patches here because they have dependencies.
 - https://patchwork.kernel.org/project/mptcp/cover/[email protected]/

v2:
 - Drop "mptcp: don't reset dst when setting default 0 tos"
   and "selftests: mptcp: sockopt: cover LINGER, REUSEADDR,
   PRIORITY, NODELAY, SYNCNT": the 'if (val > 0)' guard
   blocked the legitimate "reset to 0" path, and the test
   only ran val_in=1, missing the SK_CAN_REUSE "any non-zero
   -> 1" normalization.
 - mptcp: bump setsockopt_seq for subflow-only socket options,
   so secondary subflows created via MP_JOIN re-sync
   sk_reuse / sk_reuseport / sk_bound_dev_if from msk.
 - mptcp: copy the subflow's TOS to the msk on accept
   (alongside the existing ssk->rcv_tos copy), so MP_JOIN'd
   subflows inherit the reflected outgoing TOS.
 - mptcp: propagate sk_reuseport to subflows via
   sync_socket_options, so secondary subflows inherit
   SO_REUSEPORT, not just SO_REUSEADDR.
 - mptcp: tighten TCP_SYNCNT bounds check
   ('val < 1 || val > MAX_TCP_SYNCNT'), so out-of-bounds
   values are rejected even when msk has no subflows yet
   (where __mptcp_setsockopt_set_val would otherwise return 0
   without invoking the set_val callback).
 - https://patchwork.kernel.org/project/mptcp/cover/[email protected]/

v1:
 - https://patchwork.kernel.org/project/mptcp/cover/[email protected]/

David 'equinox' Lamparter (1):
  mptcp: sockopt: implement IPV6_TCLASS

Gang Yan (1):
  mptcp: take TCP_MAXSEG handling into setsockopt_set_val

Geliang Tang (9):
  mptcp: handle TCP_MAXSEG getsockopt in common case
  mptcp: inherit sk_reuse/sk_reuseport and fix dev bind override
  mptcp: add TCP_SYNCNT setsockopt/getsockopt
  mptcp: skip ip6 options on v4-mapped clone
  mptcp: report v4-mapped subflow addrs as IPv4
  ipv6: extract and export ip6_sock_set_tclass helpers
  mptcp: copy the subflow's tos/tclass to the msk on accept
  nvme-tcp: support IPv6 traffic class
  nvmet-tcp: support IPv6 traffic class

 drivers/nvme/host/fabrics.c | 18 ++++++++
 drivers/nvme/host/fabrics.h |  3 ++
 drivers/nvme/host/tcp.c     |  8 +++-
 drivers/nvme/target/tcp.c   |  8 ++++
 include/net/ipv6.h          |  3 ++
 net/ipv6/ipv6_sockglue.c    | 31 +++++++++----
 net/mptcp/protocol.c        | 20 ++++++++-
 net/mptcp/sockopt.c         | 89 ++++++++++++++++++++++++++++++++++---
 net/mptcp/subflow.c         |  4 +-
 9 files changed, 166 insertions(+), 18 deletions(-)

-- 
2.53.0
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.