From: sashiko-bot@kernel.org
To: "Michal Luczaj" <mhal@rbox.co>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
virtualization@lists.linux.dev,
"Eugenio Perez" <eperezma@redhat.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH net v2 2/5] vsock/virtio: Streamline socket reset on transport/PM event
Date: Wed, 16 Sep 2026 13:15:58 +0000 [thread overview]
Message-ID: <20260916131559.28D9B1F00898@smtp.kernel.org> (raw)
In-Reply-To: <20260915-vsock-connect-reset-closing-v2-2-a1d9abb472f7@rbox.co>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] vsock: lost peer_shutdown update in lockless reset
--
commit c52d0f36e0857217fee2a98454aaab9edf069cc3
Author: Michal Luczaj <mhal@rbox.co>
vsock/virtio: Streamline socket reset on transport/PM event
This commit streamlines socket resets on transport or power management
events by setting SHUTDOWN_MASK in virtio_vsock_reset_sock(). It aligns
the virtio transport with similar behavior in vhost and VMCI.
> diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
> --- a/net/vmw_vsock/virtio_transport.c
> +++ b/net/vmw_vsock/virtio_transport.c
[ ... ]
> static void virtio_vsock_reset_sock(struct sock *sk)
> {
> + struct vsock_sock *vsk = vsock_sk(sk);
> +
> /* vmci_transport.c doesn't take sk_lock here either. At least we're
> * under vsock_table_lock so the sock cannot disappear while we're
> * executing.
> */
>
> + vsk->peer_shutdown = SHUTDOWN_MASK;
[Severity: Medium]
Could this lockless assignment race with the lock-protected read-modify-write
in the RX path?
Looking at virtio_transport_recv_connected(), it processes
VIRTIO_VSOCK_OP_SHUTDOWN while holding sk_lock. It reads vsk->peer_shutdown
via READ_ONCE(), applies a bitwise OR (such as peer_shutdown |= RCV_SHUTDOWN),
and writes it back with WRITE_ONCE().
If the lockless assignment here occurs between the RX thread's read and
write, could the RX thread overwrite SHUTDOWN_MASK with its local value,
dropping the SEND_SHUTDOWN state?
If this lost update occurs, it seems the socket would lose its full shutdown
state. Would this cause vsock_poll() to miss setting EPOLLHUP and EPOLLRDHUP
flags, breaking API expectations?
Additionally, might this plain write trigger KCSAN data race warnings against
concurrent READ_ONCE() calls?
> sk->sk_state = TCP_CLOSE;
> sk->sk_err = ECONNRESET;
> sk_error_report(sk);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260915-vsock-connect-reset-closing-v2-0-a1d9abb472f7@rbox.co?part=2
next prev parent reply other threads:[~2026-09-16 13:15 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 13:15 [PATCH net v2 0/5] vsock: Fix connect() races Michal Luczaj
2026-09-15 13:15 ` [PATCH net v2 1/5] vhost/vsock: Fix socket state constant Michal Luczaj
2026-09-16 12:28 ` Stefano Garzarella
2026-09-16 13:15 ` sashiko-bot
2026-09-15 13:15 ` [PATCH net v2 2/5] vsock/virtio: Streamline socket reset on transport/PM event Michal Luczaj
2026-09-16 12:30 ` Stefano Garzarella
2026-09-22 13:17 ` Michal Luczaj
2026-09-24 10:06 ` Stefano Garzarella
2026-09-24 21:26 ` Michal Luczaj
2026-09-16 13:15 ` sashiko-bot [this message]
2026-09-16 23:39 ` netdev-bot+sashiko
2026-09-15 13:15 ` [PATCH net v2 3/5] vsock: Enforce no-transport invariant for TCP_LISTEN sockets Michal Luczaj
2026-09-16 12:30 ` Stefano Garzarella
2026-09-22 13:18 ` Michal Luczaj
2026-09-24 10:17 ` Stefano Garzarella
2026-09-24 21:26 ` Michal Luczaj
2026-09-28 10:31 ` Stefano Garzarella
2026-10-05 7:58 ` Michal Luczaj
2026-09-16 13:15 ` sashiko-bot
2026-09-16 23:39 ` netdev-bot+sashiko
2026-09-15 13:15 ` [PATCH net v2 4/5] vsock: Do not reset a TCP_CLOSING socket Michal Luczaj
2026-09-16 12:30 ` Stefano Garzarella
2026-09-22 13:17 ` Michal Luczaj
2026-09-16 13:16 ` sashiko-bot
2026-09-16 23:39 ` netdev-bot+sashiko
2026-09-15 13:15 ` [PATCH net v2 5/5] vsock: Handle sudden TCP_CLOSE during connect Michal Luczaj
2026-09-16 12:31 ` Stefano Garzarella
2026-09-22 13:18 ` Michal Luczaj
2026-09-28 10:44 ` Stefano Garzarella
2026-09-16 13:16 ` sashiko-bot
2026-09-16 23:39 ` netdev-bot+sashiko
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=20260916131559.28D9B1F00898@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=eperezma@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mhal@rbox.co \
--cc=mst@redhat.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=virtualization@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox