[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v3 0/5] iotests: Let 233 run concurrently

From: Eric Blake
Subject: Re: [Qemu-block] [PATCH v3 0/5] iotests: Let 233 run concurrently
Date: Fri, 24 May 2019 08:53:25 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 5/8/19 4:18 PM, Max Reitz wrote:
> Currently, 233 cannot reliably run concurrently to other NBD TCP tests.
> When it starts, it looks for a free port and then attempts to use that
> for the whole duration of the test run.  This is a TOCTTOU race
> condition: It does not reserve that port, so another NBD TCP test that
> runs in parallel can grab it.
> To fix this, we must not use the same port all the time, but always
> choose a new one when qemu-nbd is started.  We cannot check whether it
> is free, but must let qemu-nbd do so and take it atomically.  We can
> achieve this by using the existing --fork option.
> There are two problems with --fork, however.  First, it does not give us
> a chance to reliably get the server’s PID, which we need.  We can change
> that by letting qemu-nbd (optionally) write a PID file, though.  (Which
> makes sense if we have a daemon mode.)
> Second, it currently discards all output after the server has been
> started.  That looks like an accident to me, because we clearly try to
> restore the old stderr channel after having redirected all startup
> messages to the parent process.  If it is a bug, we can fix it.
> v3:
> - Patch 1: Dropped “pid_file” variable, so it actually compiles...

Thanks; will apply to my NBD tree, and send a PR Monday.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]