Re: [PATCH net] vsock: Ignore signal/timeout on connect() if already established
From: Michal Luczaj <hidden>
Date: 2026-01-23 16:52:52
Also in:
lkml, virtualization
On 11/24/25 12:49, Stefano Garzarella wrote:
On Sun, Nov 23, 2025 at 10:46:22PM +0100, Michal Luczaj wrote:quoted
On 11/21/25 10:21, Stefano Garzarella wrote:quoted
On Thu, Nov 20, 2025 at 10:12:20PM +0100, Michal Luczaj wrote:quoted
On 11/19/25 20:52, Michal Luczaj wrote:quoted
... To follow up, should I add a version of syzkaller's lockdep warning repro to vsock test suite? In theory it could test this fix here as well, but in practice the race window is small and hitting it (the brute way) takes prohibitively long.Replying to self to add more data. After reverting f7c877e75352 ("vsock: fix lock inversion in vsock_assign_transport()") 002541ef650b ("vsock: Ignore signal/timeout on connect() if already established") adding--- a/tools/testing/vsock/vsock_test.c +++ b/tools/testing/vsock/vsock_test.c@@ -2014,6 +2014,7 @@ static void test_stream_transport_change_client(conststruct test_opts *opts) perror("socket"); exit(EXIT_FAILURE); } + enable_so_linger(s, 1); ret = connect(s, (struct sockaddr *)&sa, sizeof(sa)); /* The connect can fail due to signals coming from the is enough for vsock_test to trigger the lockdep warning syzkaller found.cool, so if it's only that, maybe is worth adding.Ok, there it is: https://lore.kernel.org/netdev/20251123-vsock_test-linger-lockdep-warn-v1-1-4b1edf9d8cdc@rbox.co/ (local)Great!quoted
And circling back to [1], let me know if you think it's worth adding to the suit. I guess it would test the case #2 from [2], but it'd take another 2sIf you think it is better to put them in vsock tests, instead of bpf, it's fine by me. 2s more is okay IMO.
OK, here's a followup: https://lore.kernel.org/bpf/20260123-selftest-signal-on-connect-v1-0-b0256e7025b6@rbox.co/ (local) [...]