On 11/24/25 12:49, Stefano Garzarella wrote:
> On Sun, Nov 23, 2025 at 10:46:22PM +0100, Michal Luczaj wrote:
>> On 11/21/25 10:21, Stefano Garzarella wrote:
>>> On Thu, Nov 20, 2025 at 10:12:20PM +0100, Michal Luczaj wrote:
>>>> On 11/19/25 20:52, Michal Luczaj wrote:
>>>>> ...
>>>>> 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(const
>>>> struct 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-4b1edf9d8...@rbox.co/
>
> Great!
>
>>
>> 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 2s
>
> If 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/[email protected]/
[...]
>> [1]:
>> https://lore.kernel.org/netdev/fjy4jaww6xualdudevfuyoavnrbu45cg4d7erv4rttde363xfc@nahglijbl2eg/
>> [2]:
>> https://lore.kernel.org/netdev/[email protected]/
