Thread (3 messages) flat view 3 messages, 3 authors, 2d ago

Re: [PATCH net] mptcp: return sk_wait_data() errors from recvmsg()

From: Matthieu Baerts <matttbe@kernel.org>
Date: 2026-09-13 17:47:13
Also in: lkml, mptcp

Hi Mark,

On 13/09/2026 12:30, Mark Amirkan via B4 Relay wrote:
From: Mark Amirkan <redacted>

Commit 581302298524 ("mptcp: error out earlier on disconnect") made
mptcp_recvmsg() stop when sk_wait_data() returns an error.  The error is
stored in err, but the function then jumps to a path which returns
copied.  When no data was copied, recvmsg() therefore returns zero and
reports a false EOF.

Store the result in copied, which is the value returned by the function.
This also keeps the usual partial-read result when data was copied before
the error.
Good catch! Indeed, it looks like it is a typo and "copied" was supposed
to be assigned.

Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

@Net maintainers: can you please apply it directly in the net tree? (if
no issues are spot by Clashiko) No need to take a detour via the MPTCP
tree for this fix.
A recvmsg() blocked in one thread reproduces the issue when another
thread disconnects the same MPTCP socket with connect(AF_UNSPEC).
Before this change recvmsg() returns zero; afterwards it returns -EPIPE.
I see that our test suite currently doesn't exercise this error path. By
chance, do you have a reproducer to avoid similar regressions later on?
Ideally, one using Packetdrill, the MPTCP fork in this case [1].

[1] https://github.com/multipath-tcp/packetdrill

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help