summaryrefslogtreecommitdiff
path: root/stubs
diff options
context:
space:
mode:
authorStefan Hajnoczi <stefanha@redhat.com>2017-08-15 14:05:02 +0100
committerEric Blake <eblake@redhat.com>2017-08-15 10:03:27 -0500
commitcbaddb25b20060fa0b0a2a46d5ccca65cffd1a6f (patch)
treefa73448dd4cd9b0e8a5b76db794a0f14f8a1b765 /stubs
parentdad3946ec64164b1855e09991be0dfc4358298b4 (diff)
downloadqemu-cbaddb25b20060fa0b0a2a46d5ccca65cffd1a6f.tar.gz
qemu-iotests: step clock after each test iteration
The 093 throttling test submits twice as many requests as the throttle limit in order to ensure that we reach the limit. The remaining requests are left in-flight at the end of each test iteration. Commit 452589b6b47e8dc6353df257fc803dfc1383bed8 ("vl.c/exit: pause cpus before closing block devices") exposed a hang in 093. This happens because requests are still in flight when QEMU terminates but QEMU_CLOCK_VIRTUAL time is frozen. bdrv_drain_all() hangs forever since throttled requests cannot complete. Step the clock at the end of each test iteration so in-flight requests actually finish. This solves the hang and is cleaner than leaving tests in-flight. Note that this could also be "fixed" by disabling throttling when drives are closed in QEMU. That approach has two issues: 1. We must drain requests before disabling throttling, so the hang cannot be easily avoided! 2. Any time QEMU disables throttling internally there is a chance that malicious users can abuse the code path to bypass throttling limits. Therefore it makes more sense to fix the test case than to modify QEMU. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20170815130502.8736-1-stefanha@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com>
Diffstat (limited to 'stubs')
0 files changed, 0 insertions, 0 deletions