Re: [PATCH mptcp-next v4 0/4] mptcp: MSG_ERRQUEUE support on the parent socket

[Matthieu Baerts <matttbe@kernel.org>]

On 01/05/2026 17:28, David CARLIER wrote:
> Hi Matthieu,
> 
>   On 01/05/2026 16:49, Matthieu Baerts wrote:
>   > It looks like the CI (and sashiko) found some issues with this series.

(Please do fix your email client to avoid this formatting: some of your
emails are OK, but not all of them.)

>   For v5:
> 
>   - 1/4: per-bit inet_assign_bit() loop instead of WRITE_ONCE(), keeps
>     atomicity.
>   - 2/4: add missing sockopt_seq_inc(msk).
>   - 2/4: skip family-mismatched subflows in the v4/v6 helpers.
>   - 2/4: snapshot optval to a local int, pass KERNEL_SOCKPTR(&val) into
>     the loop.

(While at it, your new helpers mptcp_setsockopt_v[46]_recverr could have
a generic name)

>   - 3/4: pull-on-drain from mptcp_recv_error() so a parent-ENOMEM does
>     not strand subflow skbs.
> 
>   Will also re-run the docker repro to check the selftest_mptcp_join /
>   packetdrill rows are pre-existing.

The packetdrill errors might be pre-existing, someone should look at
improving the situation there:

  https://ci-results.mptcp.dev/flakes.html

>   > But globally, I'm a bit puzzled: with MPTCP, there might be multiple
>   > paths being used, and reporting errors about all of them when the
>   > "legacy" RECVERR socket options are used will confuse the userspace
>   > that doesn't (have to) know multiple subflows are being used.
> 
>   Fair, and Paolo raised it on v3. The use-case is tx timestamping and
>   MSG_ZEROCOPY completions - both are tied to user data, not the
>   subflow that carried it, so no subflow identity leaks into the cmsg.
>   ICMP/ICMPv6 is the part that does. v5 will filter the splice by
>   SO_EE_ORIGIN: forward TIMESTAMPING / ZEROCOPY / LOCAL, drop ICMP.

Maybe OK with this filter indeed..

>   > It might be easier to have a dedicated MPTCP_RECERR, and
> eventually
>   > propagate more MPTCP-specific messages. Something that could be
>   > linked to:
>   >   https://github.com/multipath-tcp/mptcp_net-next/issues/78
> 
>   Agreed - subflow ICMP and #78's lifecycle events belong there. As a
>   follow-up once v5 lands.

Indeed, better to split them.

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.