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