All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Carlier <devnexen@gmail.com>
To: mptcp@lists.linux.dev
Cc: matttbe@kernel.org, martineau@kernel.org, geliang@kernel.org,
	pabeni@redhat.com, David Carlier <devnexen@gmail.com>
Subject: [PATCH mptcp-next v9 0/4] mptcp: MSG_ERRQUEUE support on the parent socket
Date: Thu, 28 May 2026 06:54:54 +0100	[thread overview]
Message-ID: <20260528055459.55133-1-devnexen@gmail.com> (raw)

This series lets MPTCP applications use poll(EPOLLERR) and
recvmsg(MSG_ERRQUEUE) on the parent socket to drain TX timestamps,
MSG_ZEROCOPY completion notifications and SO_EE_ORIGIN_LOCAL events
that are produced by the subflows, the same way they would on a plain
TCP socket. ICMP-derived errors stay on the subflow queue: the legacy
RECVERR ABI cannot convey their per-subflow peer identity, and they
are intended for a future MPTCP_RECERR channel.

Patch 1 factors the existing inet_flags subflow-propagation hard-coded
list into a mask, so subsequent patches can extend it without churn.

Patch 2 makes IP_RECVERR / IPV6_RECVERR (and the RFC4884 variants)
propagate to the subflows. The parent stores the bit so MPTCP-aware
helpers can branch on it.

Patch 3 splices subflow err-skbs onto the parent's sk_error_queue at
error-report time. When the parent's err queue is full, the splice
drops the offending skb (matching ip_icmp_error() / ipv6_icmp_error()
behaviour). mptcp_recvmsg(MSG_ERRQUEUE) forwards directly to
inet_recv_error(), and mptcp_poll() advertises EPOLLERR purely on the
parent's sk_err / sk_error_queue, matching tcp_poll().

Patch 4 is a selftest covering the propagation path.

Changes in v9 (addresses sashiko v8 review,
https://sashiko.dev/#/patchset/cover.1779890764.git.devnexen@gmail.com):
 - patch 2/4: don't propagate the v6-only RECVERR6 bits onto v4
   subflows in sync_socket_options(); matches the SOL_IPV6 skip already
   performed in mptcp_setsockopt_all_sf(). The bits were never read on
   an AF_INET subflow, but left existing and newly-joined subflows
   inconsistent. (sashiko v8, Low)
 - patch 3/4: don't break the __mptcp_error_report() subflow scan after
   a bare errqueue splice; only break on a real sk_err. Splicing one
   subflow's error queue no longer short-circuits the loop and leaves
   the remaining subflows' pending notifications undrained. (sashiko
   v8, High)

v8: https://lore.kernel.org/mptcp/cover.1779890764.git.devnexen@gmail.com/

David Carlier (4):
  mptcp: sockopt: factor inet_flags propagation into a mask
  mptcp: propagate RECVERR sockopts to subflows
  mptcp: support MSG_ERRQUEUE on the parent socket
  selftests: mptcp: cover IP_RECVERR sockopt propagation

 net/mptcp/protocol.c                          |  55 +++++--
 net/mptcp/sockopt.c                           | 144 +++++++++++++++---
 .../selftests/net/mptcp/mptcp_sockopt.c       |  55 +++++++
 3 files changed, 221 insertions(+), 33 deletions(-)


base-commit: 6ae41d6df6c12883277b2c9ab490b5c8b1a4fc85
-- 
2.53.0


             reply	other threads:[~2026-05-28  5:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-28  5:54 David Carlier [this message]
2026-05-28  5:54 ` [PATCH mptcp-next v9 1/4] mptcp: sockopt: factor inet_flags propagation into a mask David Carlier
2026-05-28  5:54 ` [PATCH mptcp-next v9 2/4] mptcp: propagate RECVERR sockopts to subflows David Carlier
2026-05-28  5:54 ` [PATCH mptcp-next v9 3/4] mptcp: support MSG_ERRQUEUE on the parent socket David Carlier
2026-05-28  5:54 ` [PATCH mptcp-next v9 4/4] selftests: mptcp: cover IP_RECVERR sockopt propagation David Carlier
2026-05-28  7:02 ` [PATCH mptcp-next v9 0/4] mptcp: MSG_ERRQUEUE support on the parent socket MPTCP CI

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260528055459.55133-1-devnexen@gmail.com \
    --to=devnexen@gmail.com \
    --cc=geliang@kernel.org \
    --cc=martineau@kernel.org \
    --cc=matttbe@kernel.org \
    --cc=mptcp@lists.linux.dev \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.