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 v10 0/4] mptcp: MSG_ERRQUEUE support on the parent socket
Date: Fri, 29 May 2026 18:45:18 +0100	[thread overview]
Message-ID: <20260529174524.260199-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. MSG_ZEROCOPY completions are queued unconditionally
so a notification is never lost, mirroring tcp's
__msg_zerocopy_callback() which bypasses sk_rcvbuf for the same reason.
Timestamp and local events go through sock_queue_err_skb() and may be
dropped under rmem pressure, matching tcp's tx-timestamp path and
ip_icmp_error() / ipv6_icmp_error(). 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 v10 (addresses sashiko v9 review,
https://sashiko.dev/#/patchset/20260528055459.55133-1-devnexen@gmail.com):
 - patch 2/4: reject IPV6_RECVERR / IPV6_RECVERR_RFC4884 set/getsockopt
   on an AF_INET socket with -ENOPROTOOPT instead of routing a v4 socket
   into the v6 handler; matches plain TCP and removes a latent pinet6
   deref hazard. (sashiko v9, Medium)
 - patch 3/4: never drop MSG_ZEROCOPY completions. They are queued to
   the parent regardless of sk_rcvbuf, like tcp's
   __msg_zerocopy_callback(); previously a full parent err queue could
   drop them under receive-buffer pressure and leak the pinned userspace
   pages. (sashiko v9, High)

v9: https://lore.kernel.org/mptcp/20260528055459.55133-1-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                          |  68 ++++++--
 net/mptcp/sockopt.c                           | 151 +++++++++++++++---
 .../selftests/net/mptcp/mptcp_sockopt.c       |  55 +++++++
 3 files changed, 241 insertions(+), 33 deletions(-)


base-commit: 6ae41d6df6c12883277b2c9ab490b5c8b1a4fc85
--
2.53.0


             reply	other threads:[~2026-05-29 17:45 UTC|newest]

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

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=20260529174524.260199-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.