From: "Alex Bennée" <alex.bennee@linaro.org>
To: Laurent Vivier <lvivier@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, qemu-devel@nongnu.org
Subject: Re: netdev-socket test hang (s390 host, mips64el guest, backtrace)
Date: Mon, 17 Apr 2023 11:16:11 +0100 [thread overview]
Message-ID: <87cz4295j1.fsf@linaro.org> (raw)
In-Reply-To: <dda6039e-2826-c32f-b0ec-d5988808a1a1@redhat.com>
Laurent Vivier <lvivier@redhat.com> writes:
> Hi Peter,
>
> On 4/13/23 14:05, Peter Maydell wrote:
>> On Thu, 13 Apr 2023 at 11:50, Peter Maydell <peter.maydell@linaro.org> wrote:
>>>
>>> I just found a hung netdev-socket test on our s390 CI runner.
>>> Looks like a deadlock, no processes using CPU.
>>> Here's the backtrace; looks like both QEMU processes are sat
>>> idle but the test process is sat waiting forever for something
>>> in test_stream_inet_reconnect(). Any ideas?
>> May well not be related, but I think there's a race condition
>> in this test's inet_get_free_port() code. The code tries
>> to find a free port number by creating a socket, looking
>> at what port it is bound to, and then closing the socket.
>> If there are several copies of this test running at once
>> (as is plausible in a 'make -j8' setup), then you can
>> get an interleaving:
>> test 1 test 2
>> find a port number
>> close the socket
>> find a port number
>> (get the same number as test 1)
>> close the socket
>> use port number for test
>> use port number for test
>> (fail because of test 1)
>>
>
> I don't see an easy way to avoid to race, but perhaps we can change
> the test to use unix socket rather than inet one? In this case we can
> use an unique name.
We could use a lock file that would stop the test clashing with itself
(although another process on the machine could still race for the
socket). The unix socket would be easier but wouldn't we loose test
coverage or do we not care about the exact details for this test?
>
> Thanks,
> Laurent
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2023-04-17 10:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-13 10:50 netdev-socket test hang (s390 host, mips64el guest, backtrace) Peter Maydell
2023-04-13 12:05 ` Peter Maydell
2023-04-17 9:06 ` Laurent Vivier
2023-04-17 10:16 ` Alex Bennée [this message]
2023-04-17 13:02 ` Laurent Vivier
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=87cz4295j1.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=lvivier@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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;
as well as URLs for NNTP newsgroup(s).