* [PATCH net v6 0/2] vsock/bpf: fix recvmsg deadlock and zero-length, OOB, errqueue reads
@ 2026-11-14 11:59 ` Jerome Mohm via B4 Relay
0 siblings, 0 replies; 9+ messages in thread
From: Jerome Mohm via B4 Relay @ 2026-11-14 11:59 UTC (permalink / raw)
To: Stefano Garzarella, Bobby Eshleman, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Michael S. Tsirkin,
Alexei Starovoitov
Cc: Michal Luczaj, virtualization, netdev, linux-kernel, bpf, stable,
Jerome Mohm
On a vsock socket in a sockmap, a blocking recv() deadlocks with the
virtio delivery worker and stops all vsock rx on that worker, and
zero-length, MSG_OOB and MSG_ERRQUEUE reads spin with the lock held,
wait, or consume stream bytes. Both come from the commit that added
sockmap support. Patch 1 hands those reads to __vsock_recvmsg(), and
patch 2 releases the lock around the wait and makes the wait loop.
The deadlock and the MSG_ERRQUEUE case were found with the help of
Anthropic's Claude, with Stefano adding the stream-byte part; the other
cases come from the netdev Sashiko reviews and Alexei. The reproducers
are available on request.
Changes in v6:
- Split into two patches, the zero-length, MSG_OOB and MSG_ERRQUEUE
early return first, as Stefano preferred; the deadlock fix does not
need it. This is the reverse of the v3 and v4 order, and 2/2 no
longer argues for one patch.
- 2/2: check the transport in the wait loop before the data, so a
reader that wakes after a failed connect() has dropped the transport
no longer calls the data check, which warns (netdev Sashiko review).
I check the transport instead of swapping the two tests because
hv_sock reports the peer's FIN from its has_data() callback. The
WARN_ON_ONCE() at the top of vsock_bpf_recvmsg() is unchanged.
- 2/2: reword the comment above vsock_rx_done() (Sashiko).
- 2/2: leave Sashiko's signal-and-timeout point as is: such a reader
gets -EAGAIN where a native one gets -EINTR (see my v5 reply).
- Rebase onto current net.
- Link to v5: https://patch.msgid.link/20261109-kbh3-1-022-fix-v2-v5-1-4d9af04f0fad@eldare.de
Changes in v5: one patch on Alexei's approach, falling back to
__vsock_recvmsg() instead of copying its return values, which also
replaced the v4 comments; covers the Sashiko review of v4; don't cite
the selftests as coverage of the wait (Alexei).
Changes in v4: comments, one data <= 0 check and message changes
(Stefano); rebase; retest with a new dataless-wakeup reproducer.
Changes in v3: split into two patches after Michal's note; end the
wait after a reset read with SO_ERROR, and MSG_OOB returns -EOPNOTSUPP
(Sashiko).
Changes in v2: loop in the wait and stop on sk_err and peer shutdown,
len == 0 guard (Sashiko); MSG_ERRQUEUE to the native path.
Not tested: the lost-transport case and SHUT_RD with a pending socket
error (both checked in the code only), transports other than
virtio-vsock (PCI) and vsock-loopback, more than one run per
reproducer, a sockmap delete while a reader sleeps, the signal and
timeout case above, the vmtest.sh ns_* tests, W=1 builds beyond
vsock_bpf.o, the selftests on patch 1 alone, and anything after the
rebase: the runs were on the previous net head, and the rebase leaves
vsock_bpf.c unchanged.
Still left for separate patches, as in v5: data that sits only in
psock->ingress_skb (the loop can now reach that case after a wakeup
without data), and READ_ONCE()/WRITE_ONCE() for the lockless accesses.
---
Jerome Mohm (2):
vsock/bpf: fix zero-length, MSG_OOB and MSG_ERRQUEUE reads
vsock/bpf: release sock lock while waiting for data in recvmsg
net/vmw_vsock/vsock_bpf.c | 45 ++++++++++++++++++++++++++++++---------------
1 file changed, 30 insertions(+), 15 deletions(-)
---
base-commit: ead6fa9a0ab194f02a2f36d634b193e9c5f9a1c6
change-id: 20261001-kbh3-1-022-fix-v2-e3f14290641a
Best regards,
--
Jerome Mohm <jrmmhm.kernel@eldare.de>
^ permalink raw reply [flat|nested] 9+ messages in thread* [PATCH net v6 1/2] vsock/bpf: fix zero-length, MSG_OOB and MSG_ERRQUEUE reads
2026-11-14 11:59 ` Jerome Mohm via B4 Relay
@ 2026-11-14 11:59 ` Jerome Mohm via B4 Relay
-1 siblings, 0 replies; 9+ messages in thread
From: Jerome Mohm @ 2026-11-14 11:59 UTC (permalink / raw)
To: Stefano Garzarella, Bobby Eshleman, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Michael S. Tsirkin,
Alexei Starovoitov
Cc: Michal Luczaj, virtualization, netdev, linux-kernel, bpf, stable,
Jerome Mohm
On a vsock socket in a sockmap, vsock_bpf_recvmsg() sends zero-length,
MSG_OOB and MSG_ERRQUEUE reads down the sockmap path whenever the psock
queue has data or nothing is queued at all. That path copies from the
psock queue and waits for data, and it handles none of these reads:
- a zero-length read with data in the psock queue spins with the
socket lock held, and the delivery worker blocks on that lock;
- MSG_ERRQUEUE consumes stream bytes from the psock queue, and the
zero-length MSG_ERRQUEUE read that MSG_ZEROCOPY users make to collect
completions gets -EAGAIN or blocks instead of reading the error
queue;
- MSG_OOB consumes ordinary stream bytes or waits for data, where a
connected native socket returns -EOPNOTSUPP.
Hand these reads to __vsock_recvmsg(), the path of a socket outside a
sockmap, which does not wait for any of them. They now take one path,
so the order of the checks no longer matters.
The MSG_ERRQUEUE case was found with the help of Anthropic's Claude,
its stream-byte and MSG_ZEROCOPY parts by Stefano, and the zero-length
and MSG_OOB cases by the netdev Sashiko reviews. Each was reproduced in
a VM with a vsock-loopback socket in a sockmap, without kernel changes
or error injection. With this patch alone they behave as on a native
socket. The vsock vmtest.sh single-VM tests and the BPF sockmap
selftests pass with the series; I did not run them on this patch alone.
Fixes: 634f1a7110b4 ("vsock: support sockmap")
Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jerome Mohm <jrmmhm.kernel@eldare.de>
---
net/vmw_vsock/vsock_bpf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/vmw_vsock/vsock_bpf.c b/net/vmw_vsock/vsock_bpf.c
index 9049d2648646..c9b399f37720 100644
--- a/net/vmw_vsock/vsock_bpf.c
+++ b/net/vmw_vsock/vsock_bpf.c
@@ -80,6 +80,9 @@ static int vsock_bpf_recvmsg(struct sock *sk, struct msghdr *msg,
struct vsock_sock *vsk;
int copied;
+ if (unlikely(!len || (flags & (MSG_OOB | MSG_ERRQUEUE))))
+ return __vsock_recvmsg(sk, msg, len, flags);
+
psock = sk_psock_get(sk);
if (unlikely(!psock))
return __vsock_recvmsg(sk, msg, len, flags);
--
2.56.0
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH net v6 1/2] vsock/bpf: fix zero-length, MSG_OOB and MSG_ERRQUEUE reads
@ 2026-11-14 11:59 ` Jerome Mohm via B4 Relay
0 siblings, 0 replies; 9+ messages in thread
From: Jerome Mohm via B4 Relay @ 2026-11-14 11:59 UTC (permalink / raw)
To: Stefano Garzarella, Bobby Eshleman, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Michael S. Tsirkin,
Alexei Starovoitov
Cc: Michal Luczaj, virtualization, netdev, linux-kernel, bpf, stable,
Jerome Mohm
From: Jerome Mohm <jrmmhm.kernel@eldare.de>
On a vsock socket in a sockmap, vsock_bpf_recvmsg() sends zero-length,
MSG_OOB and MSG_ERRQUEUE reads down the sockmap path whenever the psock
queue has data or nothing is queued at all. That path copies from the
psock queue and waits for data, and it handles none of these reads:
- a zero-length read with data in the psock queue spins with the
socket lock held, and the delivery worker blocks on that lock;
- MSG_ERRQUEUE consumes stream bytes from the psock queue, and the
zero-length MSG_ERRQUEUE read that MSG_ZEROCOPY users make to collect
completions gets -EAGAIN or blocks instead of reading the error
queue;
- MSG_OOB consumes ordinary stream bytes or waits for data, where a
connected native socket returns -EOPNOTSUPP.
Hand these reads to __vsock_recvmsg(), the path of a socket outside a
sockmap, which does not wait for any of them. They now take one path,
so the order of the checks no longer matters.
The MSG_ERRQUEUE case was found with the help of Anthropic's Claude,
its stream-byte and MSG_ZEROCOPY parts by Stefano, and the zero-length
and MSG_OOB cases by the netdev Sashiko reviews. Each was reproduced in
a VM with a vsock-loopback socket in a sockmap, without kernel changes
or error injection. With this patch alone they behave as on a native
socket. The vsock vmtest.sh single-VM tests and the BPF sockmap
selftests pass with the series; I did not run them on this patch alone.
Fixes: 634f1a7110b4 ("vsock: support sockmap")
Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jerome Mohm <jrmmhm.kernel@eldare.de>
---
net/vmw_vsock/vsock_bpf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/vmw_vsock/vsock_bpf.c b/net/vmw_vsock/vsock_bpf.c
index 9049d2648646..c9b399f37720 100644
--- a/net/vmw_vsock/vsock_bpf.c
+++ b/net/vmw_vsock/vsock_bpf.c
@@ -80,6 +80,9 @@ static int vsock_bpf_recvmsg(struct sock *sk, struct msghdr *msg,
struct vsock_sock *vsk;
int copied;
+ if (unlikely(!len || (flags & (MSG_OOB | MSG_ERRQUEUE))))
+ return __vsock_recvmsg(sk, msg, len, flags);
+
psock = sk_psock_get(sk);
if (unlikely(!psock))
return __vsock_recvmsg(sk, msg, len, flags);
--
2.56.0
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH net v6 1/2] vsock/bpf: fix zero-length, MSG_OOB and MSG_ERRQUEUE reads
2026-11-14 11:59 ` Jerome Mohm via B4 Relay
(?)
@ 2026-11-14 12:24 ` sashiko-bot
-1 siblings, 0 replies; 9+ messages in thread
From: sashiko-bot @ 2026-11-14 12:24 UTC (permalink / raw)
To: Jerome Mohm; +Cc: virtualization, Michael S. Tsirkin, Eugenio Perez
> From: Jerome Mohm <jrmmhm.kernel@eldare.de>
>
> On a vsock socket in a sockmap, vsock_bpf_recvmsg() sends zero-length,
> MSG_OOB and MSG_ERRQUEUE reads down the sockmap path whenever the psock
> queue has data or nothing is queued at all. That path copies from the
> psock queue and waits for data, and it handles none of these reads:
>
> - a zero-length read with data in the psock queue spins with the
> socket lock held, and the delivery worker blocks on that lock;
> - MSG_ERRQUEUE consumes stream bytes from the psock queue, and the
> zero-length MSG_ERRQUEUE read that MSG_ZEROCOPY users make to collect
> completions gets -EAGAIN or blocks instead of reading the error
> queue;
> - MSG_OOB consumes ordinary stream bytes or waits for data, where a
> connected native socket returns -EOPNOTSUPP.
> [ ... ]
>
> Fixes: 634f1a7110b4 ("vsock: support sockmap")
> Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Jerome Mohm <jrmmhm.kernel@eldare.de>
Sashiko has reviewed this patch and found no issues.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261114-kbh3-1-022-fix-v2-v6-0-96b6029bbffa@eldare.de?part=1
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH net v6 2/2] vsock/bpf: release sock lock while waiting for data in recvmsg
2026-11-14 11:59 ` Jerome Mohm via B4 Relay
@ 2026-11-14 11:59 ` Jerome Mohm via B4 Relay
-1 siblings, 0 replies; 9+ messages in thread
From: Jerome Mohm @ 2026-11-14 11:59 UTC (permalink / raw)
To: Stefano Garzarella, Bobby Eshleman, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Michael S. Tsirkin,
Alexei Starovoitov
Cc: Michal Luczaj, virtualization, netdev, linux-kernel, bpf, stable,
Jerome Mohm
vsock_bpf_recvmsg() sleeps in vsock_msg_wait_data() with the socket lock
held, so the virtio delivery worker, which needs that lock, deadlocks
with the reader and all vsock rx on that worker stops.
Release the lock around the wait. The reader can then wake without
data, so the wait also has to loop; the fix needs both halves. The loop
ends on data, the timeout, a signal (the sleep returns at once while
one is pending), a lost transport after a failed connect(), or a state
in which __vsock_recvmsg() would not wait. Those states go to
__vsock_recvmsg(), so a non-blocking read now sees them before -EAGAIN.
A blocking read interrupted by a signal now gets -EINTR, or restarts,
instead of -EAGAIN. One tested difference remains: a reader asleep at a
virtio transport reset gets -ENOTCONN, where a native socket gets
-ECONNRESET (0 on seqpacket).
The deadlock was found with the help of Anthropic's Claude; the netdev
Sashiko reviews and Alexei found the wakeup, reset, shutdown and
lost-transport cases. Each was reproduced in a VM without kernel
changes or error injection (the resets unbind the guest's virtio-vsock
device), except the lost transport and a SHUT_RD with a pending socket
error, which were checked only in the code. With this patch the
reproduced cases behave as on a native socket, apart from the reset. I
ran the vsock vmtest.sh single-VM tests and the BPF sockmap selftests
with the series; they pass, though none of them sleeps in this wait.
Fixes: 634f1a7110b4 ("vsock: support sockmap")
Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jerome Mohm <jrmmhm.kernel@eldare.de>
---
net/vmw_vsock/vsock_bpf.c | 42 +++++++++++++++++++++++++++---------------
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/net/vmw_vsock/vsock_bpf.c b/net/vmw_vsock/vsock_bpf.c
index c9b399f37720..41307759da99 100644
--- a/net/vmw_vsock/vsock_bpf.c
+++ b/net/vmw_vsock/vsock_bpf.c
@@ -34,24 +34,37 @@ static bool vsock_has_data(struct sock *sk, struct sk_psock *psock)
return vsock_sk_has_data(sk, psock);
}
-static bool vsock_msg_wait_data(struct sock *sk, struct sk_psock *psock, long timeo)
+/* __vsock_recvmsg() doesn't wait in these states. */
+static bool vsock_rx_done(struct sock *sk)
{
- bool ret;
+ return sk->sk_err || sk->sk_state != TCP_ESTABLISHED ||
+ (sk->sk_shutdown & RCV_SHUTDOWN) ||
+ (vsock_sk(sk)->peer_shutdown & SEND_SHUTDOWN);
+}
+
+static int vsock_msg_wait_data(struct sock *sk, struct sk_psock *psock,
+ long timeo)
+{
+ struct vsock_sock *vsk = vsock_sk(sk);
+ int ret = 0;
DEFINE_WAIT_FUNC(wait, woken_wake_function);
- if (sk->sk_shutdown & RCV_SHUTDOWN)
- return true;
-
- if (!timeo)
- return false;
-
add_wait_queue(sk_sleep(sk), &wait);
sk_set_bit(SOCKWQ_ASYNC_WAITDATA, sk);
- ret = vsock_has_data(sk, psock);
- if (!ret) {
- wait_woken(&wait, TASK_INTERRUPTIBLE, timeo);
- ret = vsock_has_data(sk, psock);
+ while (vsk->transport && !vsock_has_data(sk, psock) &&
+ !vsock_rx_done(sk)) {
+ if (!timeo) {
+ ret = -EAGAIN;
+ break;
+ }
+ if (signal_pending(current)) {
+ ret = sock_intr_errno(timeo);
+ break;
+ }
+ release_sock(sk);
+ timeo = wait_woken(&wait, TASK_INTERRUPTIBLE, timeo);
+ lock_sock(sk);
}
sk_clear_bit(SOCKWQ_ASYNC_WAITDATA, sk);
remove_wait_queue(sk_sleep(sk), &wait);
@@ -105,10 +118,9 @@ static int vsock_bpf_recvmsg(struct sock *sk, struct msghdr *msg,
while (copied == 0) {
long timeo = sock_rcvtimeo(sk, flags & MSG_DONTWAIT);
- if (!vsock_msg_wait_data(sk, psock, timeo)) {
- copied = -EAGAIN;
+ copied = vsock_msg_wait_data(sk, psock, timeo);
+ if (copied)
break;
- }
if (sk_psock_queue_empty(psock)) {
release_sock(sk);
--
2.56.0
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH net v6 2/2] vsock/bpf: release sock lock while waiting for data in recvmsg
@ 2026-11-14 11:59 ` Jerome Mohm via B4 Relay
0 siblings, 0 replies; 9+ messages in thread
From: Jerome Mohm via B4 Relay @ 2026-11-14 11:59 UTC (permalink / raw)
To: Stefano Garzarella, Bobby Eshleman, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Michael S. Tsirkin,
Alexei Starovoitov
Cc: Michal Luczaj, virtualization, netdev, linux-kernel, bpf, stable,
Jerome Mohm
From: Jerome Mohm <jrmmhm.kernel@eldare.de>
vsock_bpf_recvmsg() sleeps in vsock_msg_wait_data() with the socket lock
held, so the virtio delivery worker, which needs that lock, deadlocks
with the reader and all vsock rx on that worker stops.
Release the lock around the wait. The reader can then wake without
data, so the wait also has to loop; the fix needs both halves. The loop
ends on data, the timeout, a signal (the sleep returns at once while
one is pending), a lost transport after a failed connect(), or a state
in which __vsock_recvmsg() would not wait. Those states go to
__vsock_recvmsg(), so a non-blocking read now sees them before -EAGAIN.
A blocking read interrupted by a signal now gets -EINTR, or restarts,
instead of -EAGAIN. One tested difference remains: a reader asleep at a
virtio transport reset gets -ENOTCONN, where a native socket gets
-ECONNRESET (0 on seqpacket).
The deadlock was found with the help of Anthropic's Claude; the netdev
Sashiko reviews and Alexei found the wakeup, reset, shutdown and
lost-transport cases. Each was reproduced in a VM without kernel
changes or error injection (the resets unbind the guest's virtio-vsock
device), except the lost transport and a SHUT_RD with a pending socket
error, which were checked only in the code. With this patch the
reproduced cases behave as on a native socket, apart from the reset. I
ran the vsock vmtest.sh single-VM tests and the BPF sockmap selftests
with the series; they pass, though none of them sleeps in this wait.
Fixes: 634f1a7110b4 ("vsock: support sockmap")
Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jerome Mohm <jrmmhm.kernel@eldare.de>
---
net/vmw_vsock/vsock_bpf.c | 42 +++++++++++++++++++++++++++---------------
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/net/vmw_vsock/vsock_bpf.c b/net/vmw_vsock/vsock_bpf.c
index c9b399f37720..41307759da99 100644
--- a/net/vmw_vsock/vsock_bpf.c
+++ b/net/vmw_vsock/vsock_bpf.c
@@ -34,24 +34,37 @@ static bool vsock_has_data(struct sock *sk, struct sk_psock *psock)
return vsock_sk_has_data(sk, psock);
}
-static bool vsock_msg_wait_data(struct sock *sk, struct sk_psock *psock, long timeo)
+/* __vsock_recvmsg() doesn't wait in these states. */
+static bool vsock_rx_done(struct sock *sk)
{
- bool ret;
+ return sk->sk_err || sk->sk_state != TCP_ESTABLISHED ||
+ (sk->sk_shutdown & RCV_SHUTDOWN) ||
+ (vsock_sk(sk)->peer_shutdown & SEND_SHUTDOWN);
+}
+
+static int vsock_msg_wait_data(struct sock *sk, struct sk_psock *psock,
+ long timeo)
+{
+ struct vsock_sock *vsk = vsock_sk(sk);
+ int ret = 0;
DEFINE_WAIT_FUNC(wait, woken_wake_function);
- if (sk->sk_shutdown & RCV_SHUTDOWN)
- return true;
-
- if (!timeo)
- return false;
-
add_wait_queue(sk_sleep(sk), &wait);
sk_set_bit(SOCKWQ_ASYNC_WAITDATA, sk);
- ret = vsock_has_data(sk, psock);
- if (!ret) {
- wait_woken(&wait, TASK_INTERRUPTIBLE, timeo);
- ret = vsock_has_data(sk, psock);
+ while (vsk->transport && !vsock_has_data(sk, psock) &&
+ !vsock_rx_done(sk)) {
+ if (!timeo) {
+ ret = -EAGAIN;
+ break;
+ }
+ if (signal_pending(current)) {
+ ret = sock_intr_errno(timeo);
+ break;
+ }
+ release_sock(sk);
+ timeo = wait_woken(&wait, TASK_INTERRUPTIBLE, timeo);
+ lock_sock(sk);
}
sk_clear_bit(SOCKWQ_ASYNC_WAITDATA, sk);
remove_wait_queue(sk_sleep(sk), &wait);
@@ -105,10 +118,9 @@ static int vsock_bpf_recvmsg(struct sock *sk, struct msghdr *msg,
while (copied == 0) {
long timeo = sock_rcvtimeo(sk, flags & MSG_DONTWAIT);
- if (!vsock_msg_wait_data(sk, psock, timeo)) {
- copied = -EAGAIN;
+ copied = vsock_msg_wait_data(sk, psock, timeo);
+ if (copied)
break;
- }
if (sk_psock_queue_empty(psock)) {
release_sock(sk);
--
2.56.0
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH net v6 2/2] vsock/bpf: release sock lock while waiting for data in recvmsg
2026-11-14 11:59 ` Jerome Mohm via B4 Relay
(?)
@ 2026-11-14 12:24 ` sashiko-bot
-1 siblings, 0 replies; 9+ messages in thread
From: sashiko-bot @ 2026-11-14 12:24 UTC (permalink / raw)
To: Jerome Mohm; +Cc: virtualization, Michael S. Tsirkin, Eugenio Perez
> From: Jerome Mohm <jrmmhm.kernel@eldare.de>
>
> vsock_bpf_recvmsg() sleeps in vsock_msg_wait_data() with the socket lock
> held, so the virtio delivery worker, which needs that lock, deadlocks
> with the reader and all vsock rx on that worker stops.
>
> Release the lock around the wait. The reader can then wake without
> data, so the wait also has to loop; the fix needs both halves. The loop
> ends on data, the timeout, a signal (the sleep returns at once while
> one is pending), a lost transport after a failed connect(), or a state
> in which __vsock_recvmsg() would not wait. Those states go to
> __vsock_recvmsg(), so a non-blocking read now sees them before -EAGAIN.
> A blocking read interrupted by a signal now gets -EINTR, or restarts,
> instead of -EAGAIN. One tested difference remains: a reader asleep at a
> virtio transport reset gets -ENOTCONN, where a native socket gets
> [ ... ]
>
> Fixes: 634f1a7110b4 ("vsock: support sockmap")
> Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Jerome Mohm <jrmmhm.kernel@eldare.de>
Sashiko has reviewed this patch and found no issues.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261114-kbh3-1-022-fix-v2-v6-0-96b6029bbffa@eldare.de?part=2
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net v6 0/2] vsock/bpf: fix recvmsg deadlock and zero-length, OOB, errqueue reads
2026-11-14 11:59 ` Jerome Mohm via B4 Relay
` (2 preceding siblings ...)
(?)
@ 2026-11-14 18:50 ` Alexei Starovoitov
-1 siblings, 0 replies; 9+ messages in thread
From: Alexei Starovoitov @ 2026-11-14 18:50 UTC (permalink / raw)
To: jrmmhm.kernel, Stefano Garzarella, Bobby Eshleman,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Michael S. Tsirkin, Alexei Starovoitov
Cc: Michal Luczaj, virtualization, netdev, linux-kernel, bpf, stable
On Sat Nov 14, 2026 at 11:59 AM UTC, Jerome Mohm via B4 Relay wrote:
> On a vsock socket in a sockmap, a blocking recv() deadlocks with the
> virtio delivery worker and stops all vsock rx on that worker, and
> zero-length, MSG_OOB and MSG_ERRQUEUE reads spin with the lock held,
> wait, or consume stream bytes. Both come from the commit that added
> sockmap support. Patch 1 hands those reads to __vsock_recvmsg(), and
> patch 2 releases the lock around the wait and makes the wait loop.
>
> The deadlock and the MSG_ERRQUEUE case were found with the help of
> Anthropic's Claude, with Stefano adding the stream-byte part; the other
> cases come from the netdev Sashiko reviews and Alexei. The reproducers
> are available on request.
>
> Changes in v6:
> - Split into two patches, the zero-length, MSG_OOB and MSG_ERRQUEUE
> early return first, as Stefano preferred; the deadlock fix does not
> need it. This is the reverse of the v3 and v4 order, and 2/2 no
> longer argues for one patch.
> - 2/2: check the transport in the wait loop before the data, so a
> reader that wakes after a failed connect() has dropped the transport
> no longer calls the data check, which warns (netdev Sashiko review).
> I check the transport instead of swapping the two tests because
> hv_sock reports the peer's FIN from its has_data() callback. The
> WARN_ON_ONCE() at the top of vsock_bpf_recvmsg() is unchanged.
> - 2/2: reword the comment above vsock_rx_done() (Sashiko).
> - 2/2: leave Sashiko's signal-and-timeout point as is: such a reader
> gets -EAGAIN where a native one gets -EINTR (see my v5 reply).
> - Rebase onto current net.
> - Link to v5: https://patch.msgid.link/20261109-kbh3-1-022-fix-v2-v5-1-4d9af04f0fad@eldare.de
thanks. lgtm.
^ permalink raw reply [flat|nested] 9+ messages in thread