2009-10-22 19:54:37 +04:00
|
|
|
/*
|
|
|
|
* QEMU System Emulator
|
|
|
|
*
|
|
|
|
* Copyright (c) 2003-2008 Fabrice Bellard
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "qemu-common.h"
|
2012-12-17 21:19:44 +04:00
|
|
|
#include "block/aio.h"
|
2013-03-07 16:41:47 +04:00
|
|
|
#include "block/thread-pool.h"
|
2012-12-17 21:20:00 +04:00
|
|
|
#include "qemu/main-loop.h"
|
2014-07-07 17:18:04 +04:00
|
|
|
#include "qemu/atomic.h"
|
2009-10-22 19:54:38 +04:00
|
|
|
|
2009-10-22 19:54:37 +04:00
|
|
|
/***********************************************************/
|
|
|
|
/* bottom halves (can be seen as timers which expire ASAP) */
|
|
|
|
|
|
|
|
struct QEMUBH {
|
2012-09-24 20:44:14 +04:00
|
|
|
AioContext *ctx;
|
2009-10-22 19:54:37 +04:00
|
|
|
QEMUBHFunc *cb;
|
|
|
|
void *opaque;
|
|
|
|
QEMUBH *next;
|
2012-04-29 21:08:45 +04:00
|
|
|
bool scheduled;
|
|
|
|
bool idle;
|
|
|
|
bool deleted;
|
2009-10-22 19:54:37 +04:00
|
|
|
};
|
|
|
|
|
2012-10-30 02:45:23 +04:00
|
|
|
QEMUBH *aio_bh_new(AioContext *ctx, QEMUBHFunc *cb, void *opaque)
|
2009-10-22 19:54:37 +04:00
|
|
|
{
|
|
|
|
QEMUBH *bh;
|
2014-12-17 18:10:00 +03:00
|
|
|
bh = g_new(QEMUBH, 1);
|
|
|
|
*bh = (QEMUBH){
|
|
|
|
.ctx = ctx,
|
|
|
|
.cb = cb,
|
|
|
|
.opaque = opaque,
|
|
|
|
};
|
2013-07-16 08:28:58 +04:00
|
|
|
qemu_mutex_lock(&ctx->bh_lock);
|
2012-10-30 02:45:23 +04:00
|
|
|
bh->next = ctx->first_bh;
|
2013-07-16 08:28:58 +04:00
|
|
|
/* Make sure that the members are ready before putting bh into list */
|
|
|
|
smp_wmb();
|
2012-10-30 02:45:23 +04:00
|
|
|
ctx->first_bh = bh;
|
2013-07-16 08:28:58 +04:00
|
|
|
qemu_mutex_unlock(&ctx->bh_lock);
|
2009-10-22 19:54:37 +04:00
|
|
|
return bh;
|
|
|
|
}
|
|
|
|
|
2015-09-17 19:24:50 +03:00
|
|
|
void aio_bh_call(QEMUBH *bh)
|
|
|
|
{
|
|
|
|
bh->cb(bh->opaque);
|
|
|
|
}
|
|
|
|
|
2013-07-16 08:28:58 +04:00
|
|
|
/* Multiple occurrences of aio_bh_poll cannot be called concurrently */
|
2012-10-30 02:45:23 +04:00
|
|
|
int aio_bh_poll(AioContext *ctx)
|
2009-10-22 19:54:37 +04:00
|
|
|
{
|
2011-06-07 19:51:21 +04:00
|
|
|
QEMUBH *bh, **bhp, *next;
|
2009-10-22 19:54:37 +04:00
|
|
|
int ret;
|
2011-09-01 18:16:10 +04:00
|
|
|
|
2012-10-30 02:45:23 +04:00
|
|
|
ctx->walking_bh++;
|
2009-10-22 19:54:37 +04:00
|
|
|
|
|
|
|
ret = 0;
|
2012-10-30 02:45:23 +04:00
|
|
|
for (bh = ctx->first_bh; bh; bh = next) {
|
2013-07-16 08:28:58 +04:00
|
|
|
/* Make sure that fetching bh happens before accessing its members */
|
|
|
|
smp_read_barrier_depends();
|
2011-06-07 19:51:21 +04:00
|
|
|
next = bh->next;
|
aio: strengthen memory barriers for bottom half scheduling
There are two problems with memory barriers in async.c. The fix is
to use atomic_xchg in order to achieve sequential consistency between
the scheduling of a bottom half and the corresponding execution.
First, if bh->scheduled is already 1 in qemu_bh_schedule, QEMU does
not execute a memory barrier to order any writes needed by the callback
before the read of bh->scheduled. If the other side sees req->state as
THREAD_ACTIVE, the callback is not invoked and you get deadlock.
Second, the memory barrier in aio_bh_poll is too weak. Without this
patch, it is possible that bh->scheduled = 0 is not "published" until
after the callback has returned. Another thread wants to schedule the
bottom half, but it sees bh->scheduled = 1 and does nothing. This causes
a lost wakeup. The memory barrier should have been changed to smp_mb()
in commit 924fe12 (aio: fix qemu_bh_schedule() bh->ctx race condition,
2014-06-03) together with qemu_bh_schedule()'s. Guess who reviewed
that patch?
Both of these involve a store and a load, so they are reproducible on
x86_64 as well. It is however much easier on aarch64, where the
libguestfs test suite triggers the bug fairly easily. Even there the
failure can go away or appear depending on compiler optimization level,
tracing options, or even kernel debugging options.
Paul Leveille however reported how to trigger the problem within 15
minutes on x86_64 as well. His (untested) recipe, reproduced here
for reference, is the following:
1) Qcow2 (or 3) is critical – raw files alone seem to avoid the problem.
2) Use “cache=directsync” rather than the default of
“cache=none” to make it happen easier.
3) Use a server with a write-back RAID controller to allow for rapid
IO rates.
4) Run a random-access load that (mostly) writes chunks to various
files on the virtual block device.
a. I use ‘diskload.exe c:25’, a Microsoft HCT load
generator, on Windows VMs.
b. Iometer can probably be configured to generate a similar load.
5) Run multiple VMs in parallel, against the same storage device,
to shake the failure out sooner.
6) IvyBridge and Haswell processors for certain; not sure about others.
A similar patch survived over 12 hours of testing, where an unpatched
QEMU would fail within 15 minutes.
This bug is, most likely, also the cause of failures in the libguestfs
testsuite on AArch64.
Thanks to Laszlo Ersek for initially reporting this bug, to Stefan
Hajnoczi for suggesting closer examination of qemu_bh_schedule, and to
Paul for providing test input and a prototype patch.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Reported-by: Paul Leveille <Paul.Leveille@stratus.com>
Reported-by: John Snow <jsnow@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1428419779-26062-1-git-send-email-pbonzini@redhat.com
Suggested-by: Paul Leveille <Paul.Leveille@stratus.com>
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-04-07 18:16:19 +03:00
|
|
|
/* The atomic_xchg is paired with the one in qemu_bh_schedule. The
|
|
|
|
* implicit memory barrier ensures that the callback sees all writes
|
|
|
|
* done by the scheduling thread. It also ensures that the scheduling
|
|
|
|
* thread sees the zero before bh->cb has run, and thus will call
|
|
|
|
* aio_notify again if necessary.
|
|
|
|
*/
|
|
|
|
if (!bh->deleted && atomic_xchg(&bh->scheduled, 0)) {
|
2015-07-28 19:34:09 +03:00
|
|
|
/* Idle BHs and the notify BH don't count as progress */
|
|
|
|
if (!bh->idle && bh != ctx->notify_dummy_bh) {
|
2009-10-22 19:54:37 +04:00
|
|
|
ret = 1;
|
2015-07-28 19:34:09 +03:00
|
|
|
}
|
2009-10-22 19:54:37 +04:00
|
|
|
bh->idle = 0;
|
2015-09-17 19:24:50 +03:00
|
|
|
aio_bh_call(bh);
|
2009-10-22 19:54:37 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-10-30 02:45:23 +04:00
|
|
|
ctx->walking_bh--;
|
2011-09-01 18:16:10 +04:00
|
|
|
|
2009-10-22 19:54:37 +04:00
|
|
|
/* remove deleted bhs */
|
2012-10-30 02:45:23 +04:00
|
|
|
if (!ctx->walking_bh) {
|
2013-07-16 08:28:58 +04:00
|
|
|
qemu_mutex_lock(&ctx->bh_lock);
|
2012-10-30 02:45:23 +04:00
|
|
|
bhp = &ctx->first_bh;
|
2011-09-01 18:16:10 +04:00
|
|
|
while (*bhp) {
|
|
|
|
bh = *bhp;
|
|
|
|
if (bh->deleted) {
|
|
|
|
*bhp = bh->next;
|
|
|
|
g_free(bh);
|
|
|
|
} else {
|
|
|
|
bhp = &bh->next;
|
|
|
|
}
|
|
|
|
}
|
2013-07-16 08:28:58 +04:00
|
|
|
qemu_mutex_unlock(&ctx->bh_lock);
|
2009-10-22 19:54:37 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_bh_schedule_idle(QEMUBH *bh)
|
|
|
|
{
|
|
|
|
bh->idle = 1;
|
2013-07-16 08:28:58 +04:00
|
|
|
/* Make sure that idle & any writes needed by the callback are done
|
|
|
|
* before the locations are read in the aio_bh_poll.
|
|
|
|
*/
|
aio: strengthen memory barriers for bottom half scheduling
There are two problems with memory barriers in async.c. The fix is
to use atomic_xchg in order to achieve sequential consistency between
the scheduling of a bottom half and the corresponding execution.
First, if bh->scheduled is already 1 in qemu_bh_schedule, QEMU does
not execute a memory barrier to order any writes needed by the callback
before the read of bh->scheduled. If the other side sees req->state as
THREAD_ACTIVE, the callback is not invoked and you get deadlock.
Second, the memory barrier in aio_bh_poll is too weak. Without this
patch, it is possible that bh->scheduled = 0 is not "published" until
after the callback has returned. Another thread wants to schedule the
bottom half, but it sees bh->scheduled = 1 and does nothing. This causes
a lost wakeup. The memory barrier should have been changed to smp_mb()
in commit 924fe12 (aio: fix qemu_bh_schedule() bh->ctx race condition,
2014-06-03) together with qemu_bh_schedule()'s. Guess who reviewed
that patch?
Both of these involve a store and a load, so they are reproducible on
x86_64 as well. It is however much easier on aarch64, where the
libguestfs test suite triggers the bug fairly easily. Even there the
failure can go away or appear depending on compiler optimization level,
tracing options, or even kernel debugging options.
Paul Leveille however reported how to trigger the problem within 15
minutes on x86_64 as well. His (untested) recipe, reproduced here
for reference, is the following:
1) Qcow2 (or 3) is critical – raw files alone seem to avoid the problem.
2) Use “cache=directsync” rather than the default of
“cache=none” to make it happen easier.
3) Use a server with a write-back RAID controller to allow for rapid
IO rates.
4) Run a random-access load that (mostly) writes chunks to various
files on the virtual block device.
a. I use ‘diskload.exe c:25’, a Microsoft HCT load
generator, on Windows VMs.
b. Iometer can probably be configured to generate a similar load.
5) Run multiple VMs in parallel, against the same storage device,
to shake the failure out sooner.
6) IvyBridge and Haswell processors for certain; not sure about others.
A similar patch survived over 12 hours of testing, where an unpatched
QEMU would fail within 15 minutes.
This bug is, most likely, also the cause of failures in the libguestfs
testsuite on AArch64.
Thanks to Laszlo Ersek for initially reporting this bug, to Stefan
Hajnoczi for suggesting closer examination of qemu_bh_schedule, and to
Paul for providing test input and a prototype patch.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Reported-by: Paul Leveille <Paul.Leveille@stratus.com>
Reported-by: John Snow <jsnow@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1428419779-26062-1-git-send-email-pbonzini@redhat.com
Suggested-by: Paul Leveille <Paul.Leveille@stratus.com>
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-04-07 18:16:19 +03:00
|
|
|
atomic_mb_set(&bh->scheduled, 1);
|
2009-10-22 19:54:37 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_bh_schedule(QEMUBH *bh)
|
|
|
|
{
|
2014-06-03 13:21:01 +04:00
|
|
|
AioContext *ctx;
|
|
|
|
|
|
|
|
ctx = bh->ctx;
|
2009-10-22 19:54:37 +04:00
|
|
|
bh->idle = 0;
|
aio: strengthen memory barriers for bottom half scheduling
There are two problems with memory barriers in async.c. The fix is
to use atomic_xchg in order to achieve sequential consistency between
the scheduling of a bottom half and the corresponding execution.
First, if bh->scheduled is already 1 in qemu_bh_schedule, QEMU does
not execute a memory barrier to order any writes needed by the callback
before the read of bh->scheduled. If the other side sees req->state as
THREAD_ACTIVE, the callback is not invoked and you get deadlock.
Second, the memory barrier in aio_bh_poll is too weak. Without this
patch, it is possible that bh->scheduled = 0 is not "published" until
after the callback has returned. Another thread wants to schedule the
bottom half, but it sees bh->scheduled = 1 and does nothing. This causes
a lost wakeup. The memory barrier should have been changed to smp_mb()
in commit 924fe12 (aio: fix qemu_bh_schedule() bh->ctx race condition,
2014-06-03) together with qemu_bh_schedule()'s. Guess who reviewed
that patch?
Both of these involve a store and a load, so they are reproducible on
x86_64 as well. It is however much easier on aarch64, where the
libguestfs test suite triggers the bug fairly easily. Even there the
failure can go away or appear depending on compiler optimization level,
tracing options, or even kernel debugging options.
Paul Leveille however reported how to trigger the problem within 15
minutes on x86_64 as well. His (untested) recipe, reproduced here
for reference, is the following:
1) Qcow2 (or 3) is critical – raw files alone seem to avoid the problem.
2) Use “cache=directsync” rather than the default of
“cache=none” to make it happen easier.
3) Use a server with a write-back RAID controller to allow for rapid
IO rates.
4) Run a random-access load that (mostly) writes chunks to various
files on the virtual block device.
a. I use ‘diskload.exe c:25’, a Microsoft HCT load
generator, on Windows VMs.
b. Iometer can probably be configured to generate a similar load.
5) Run multiple VMs in parallel, against the same storage device,
to shake the failure out sooner.
6) IvyBridge and Haswell processors for certain; not sure about others.
A similar patch survived over 12 hours of testing, where an unpatched
QEMU would fail within 15 minutes.
This bug is, most likely, also the cause of failures in the libguestfs
testsuite on AArch64.
Thanks to Laszlo Ersek for initially reporting this bug, to Stefan
Hajnoczi for suggesting closer examination of qemu_bh_schedule, and to
Paul for providing test input and a prototype patch.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Reported-by: Paul Leveille <Paul.Leveille@stratus.com>
Reported-by: John Snow <jsnow@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1428419779-26062-1-git-send-email-pbonzini@redhat.com
Suggested-by: Paul Leveille <Paul.Leveille@stratus.com>
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-04-07 18:16:19 +03:00
|
|
|
/* The memory barrier implicit in atomic_xchg makes sure that:
|
2014-06-03 13:21:01 +04:00
|
|
|
* 1. idle & any writes needed by the callback are done before the
|
|
|
|
* locations are read in the aio_bh_poll.
|
|
|
|
* 2. ctx is loaded before scheduled is set and the callback has a chance
|
|
|
|
* to execute.
|
2013-07-16 08:28:58 +04:00
|
|
|
*/
|
aio: strengthen memory barriers for bottom half scheduling
There are two problems with memory barriers in async.c. The fix is
to use atomic_xchg in order to achieve sequential consistency between
the scheduling of a bottom half and the corresponding execution.
First, if bh->scheduled is already 1 in qemu_bh_schedule, QEMU does
not execute a memory barrier to order any writes needed by the callback
before the read of bh->scheduled. If the other side sees req->state as
THREAD_ACTIVE, the callback is not invoked and you get deadlock.
Second, the memory barrier in aio_bh_poll is too weak. Without this
patch, it is possible that bh->scheduled = 0 is not "published" until
after the callback has returned. Another thread wants to schedule the
bottom half, but it sees bh->scheduled = 1 and does nothing. This causes
a lost wakeup. The memory barrier should have been changed to smp_mb()
in commit 924fe12 (aio: fix qemu_bh_schedule() bh->ctx race condition,
2014-06-03) together with qemu_bh_schedule()'s. Guess who reviewed
that patch?
Both of these involve a store and a load, so they are reproducible on
x86_64 as well. It is however much easier on aarch64, where the
libguestfs test suite triggers the bug fairly easily. Even there the
failure can go away or appear depending on compiler optimization level,
tracing options, or even kernel debugging options.
Paul Leveille however reported how to trigger the problem within 15
minutes on x86_64 as well. His (untested) recipe, reproduced here
for reference, is the following:
1) Qcow2 (or 3) is critical – raw files alone seem to avoid the problem.
2) Use “cache=directsync” rather than the default of
“cache=none” to make it happen easier.
3) Use a server with a write-back RAID controller to allow for rapid
IO rates.
4) Run a random-access load that (mostly) writes chunks to various
files on the virtual block device.
a. I use ‘diskload.exe c:25’, a Microsoft HCT load
generator, on Windows VMs.
b. Iometer can probably be configured to generate a similar load.
5) Run multiple VMs in parallel, against the same storage device,
to shake the failure out sooner.
6) IvyBridge and Haswell processors for certain; not sure about others.
A similar patch survived over 12 hours of testing, where an unpatched
QEMU would fail within 15 minutes.
This bug is, most likely, also the cause of failures in the libguestfs
testsuite on AArch64.
Thanks to Laszlo Ersek for initially reporting this bug, to Stefan
Hajnoczi for suggesting closer examination of qemu_bh_schedule, and to
Paul for providing test input and a prototype patch.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Reported-by: Paul Leveille <Paul.Leveille@stratus.com>
Reported-by: John Snow <jsnow@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1428419779-26062-1-git-send-email-pbonzini@redhat.com
Suggested-by: Paul Leveille <Paul.Leveille@stratus.com>
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-04-07 18:16:19 +03:00
|
|
|
if (atomic_xchg(&bh->scheduled, 1) == 0) {
|
|
|
|
aio_notify(ctx);
|
|
|
|
}
|
2009-10-22 19:54:37 +04:00
|
|
|
}
|
|
|
|
|
2013-07-16 08:28:58 +04:00
|
|
|
|
|
|
|
/* This func is async.
|
|
|
|
*/
|
2009-10-22 19:54:37 +04:00
|
|
|
void qemu_bh_cancel(QEMUBH *bh)
|
|
|
|
{
|
|
|
|
bh->scheduled = 0;
|
|
|
|
}
|
|
|
|
|
2013-07-16 08:28:58 +04:00
|
|
|
/* This func is async.The bottom half will do the delete action at the finial
|
|
|
|
* end.
|
|
|
|
*/
|
2009-10-22 19:54:37 +04:00
|
|
|
void qemu_bh_delete(QEMUBH *bh)
|
|
|
|
{
|
|
|
|
bh->scheduled = 0;
|
|
|
|
bh->deleted = 1;
|
|
|
|
}
|
|
|
|
|
2014-07-09 13:53:01 +04:00
|
|
|
int64_t
|
|
|
|
aio_compute_timeout(AioContext *ctx)
|
2009-10-22 19:54:37 +04:00
|
|
|
{
|
2014-07-09 13:53:01 +04:00
|
|
|
int64_t deadline;
|
|
|
|
int timeout = -1;
|
2009-10-22 19:54:37 +04:00
|
|
|
QEMUBH *bh;
|
|
|
|
|
2012-10-30 02:45:23 +04:00
|
|
|
for (bh = ctx->first_bh; bh; bh = bh->next) {
|
2009-10-22 19:54:37 +04:00
|
|
|
if (!bh->deleted && bh->scheduled) {
|
|
|
|
if (bh->idle) {
|
|
|
|
/* idle bottom halves will be polled at least
|
|
|
|
* every 10ms */
|
2014-07-09 13:53:01 +04:00
|
|
|
timeout = 10000000;
|
2009-10-22 19:54:37 +04:00
|
|
|
} else {
|
|
|
|
/* non-idle bottom halves will be executed
|
|
|
|
* immediately */
|
2014-07-09 13:53:01 +04:00
|
|
|
return 0;
|
2009-10-22 19:54:37 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2012-09-24 16:57:41 +04:00
|
|
|
|
2014-07-09 13:53:01 +04:00
|
|
|
deadline = timerlistgroup_deadline_ns(&ctx->tlg);
|
2013-08-21 19:02:51 +04:00
|
|
|
if (deadline == 0) {
|
2014-07-09 13:53:01 +04:00
|
|
|
return 0;
|
2013-08-21 19:02:51 +04:00
|
|
|
} else {
|
2014-07-09 13:53:01 +04:00
|
|
|
return qemu_soonest_timeout(timeout, deadline);
|
2013-08-21 19:02:51 +04:00
|
|
|
}
|
2014-07-09 13:53:01 +04:00
|
|
|
}
|
2013-08-21 19:02:51 +04:00
|
|
|
|
2014-07-09 13:53:01 +04:00
|
|
|
static gboolean
|
|
|
|
aio_ctx_prepare(GSource *source, gint *timeout)
|
|
|
|
{
|
|
|
|
AioContext *ctx = (AioContext *) source;
|
|
|
|
|
AioContext: fix broken ctx->dispatching optimization
This patch rewrites the ctx->dispatching optimization, which was the cause
of some mysterious hangs that could be reproduced on aarch64 KVM only.
The hangs were indirectly caused by aio_poll() and in particular by
flash memory updates's call to blk_write(), which invokes aio_poll().
Fun stuff: they had an extremely short race window, so much that
adding all kind of tracing to either the kernel or QEMU made it
go away (a single printf made it half as reproducible).
On the plus side, the failure mode (a hang until the next keypress)
made it very easy to examine the state of the process with a debugger.
And there was a very nice reproducer from Laszlo, which failed pretty
often (more than half of the time) on any version of QEMU with a non-debug
kernel; it also failed fast, while still in the firmware. So, it could
have been worse.
For some unknown reason they happened only with virtio-scsi, but
that's not important. It's more interesting that they disappeared with
io=native, making thread-pool.c a likely suspect for where the bug arose.
thread-pool.c is also one of the few places which use bottom halves
across threads, by the way.
I hope that no other similar bugs exist, but just in case :) I am
going to describe how the successful debugging went... Since the
likely culprit was the ctx->dispatching optimization, which mostly
affects bottom halves, the first observation was that there are two
qemu_bh_schedule() invocations in the thread pool: the one in the aio
worker and the one in thread_pool_completion_bh. The latter always
causes the optimization to trigger, the former may or may not. In
order to restrict the possibilities, I introduced new functions
qemu_bh_schedule_slow() and qemu_bh_schedule_fast():
/* qemu_bh_schedule_slow: */
ctx = bh->ctx;
bh->idle = 0;
if (atomic_xchg(&bh->scheduled, 1) == 0) {
event_notifier_set(&ctx->notifier);
}
/* qemu_bh_schedule_fast: */
ctx = bh->ctx;
bh->idle = 0;
assert(ctx->dispatching);
atomic_xchg(&bh->scheduled, 1);
Notice how the atomic_xchg is still in qemu_bh_schedule_slow(). This
was already debated a few months ago, so I assumed it to be correct.
In retrospect this was a very good idea, as you'll see later.
Changing thread_pool_completion_bh() to qemu_bh_schedule_fast() didn't
trigger the assertion (as expected). Changing the worker's invocation
to qemu_bh_schedule_slow() didn't hide the bug (another assumption
which luckily held). This already limited heavily the amount of
interaction between the threads, hinting that the problematic events
must have triggered around thread_pool_completion_bh().
As mentioned early, invoking a debugger to examine the state of a
hung process was pretty easy; the iothread was always waiting on a
poll(..., -1) system call. Infinite timeouts are much rarer on x86,
and this could be the reason why the bug was never observed there.
With the buggy sequence more or less resolved to an interaction between
thread_pool_completion_bh() and poll(..., -1), my "tracing" strategy was
to just add a few qemu_clock_get_ns(QEMU_CLOCK_REALTIME) calls, hoping
that the ordering of aio_ctx_prepare(), aio_ctx_dispatch, poll() and
qemu_bh_schedule_fast() would provide some hint. The output was:
(gdb) p last_prepare
$3 = 103885451
(gdb) p last_dispatch
$4 = 103876492
(gdb) p last_poll
$5 = 115909333
(gdb) p last_schedule
$6 = 115925212
Notice how the last call to qemu_poll_ns() came after aio_ctx_dispatch().
This makes little sense unless there is an aio_poll() call involved,
and indeed with a slightly different instrumentation you can see that
there is one:
(gdb) p last_prepare
$3 = 107569679
(gdb) p last_dispatch
$4 = 107561600
(gdb) p last_aio_poll
$5 = 110671400
(gdb) p last_schedule
$6 = 110698917
So the scenario becomes clearer:
iothread VCPU thread
--------------------------------------------------------------------------
aio_ctx_prepare
aio_ctx_check
qemu_poll_ns(timeout=-1)
aio_poll
aio_dispatch
thread_pool_completion_bh
qemu_bh_schedule()
At this point bh->scheduled = 1 and the iothread has not been woken up.
The solution must be close, but this alone should not be a problem,
because the bottom half is only rescheduled to account for rare situations
(see commit 3c80ca1, thread-pool: avoid deadlock in nested aio_poll()
calls, 2014-07-15).
Introducing a third thread---a thread pool worker thread, which
also does qemu_bh_schedule()---does bring out the problematic case.
The third thread must be awakened *after* the callback is complete and
thread_pool_completion_bh has redone the whole loop, explaining the
short race window. And then this is what happens:
thread pool worker
--------------------------------------------------------------------------
<I/O completes>
qemu_bh_schedule()
Tada, bh->scheduled is already 1, so qemu_bh_schedule() does nothing
and the iothread is never woken up. This is where the bh->scheduled
optimization comes into play---it is correct, but removing it would
have masked the bug.
So, what is the bug?
Well, the question asked by the ctx->dispatching optimization ("is any
active aio_poll dispatching?") was wrong. The right question to ask
instead is "is any active aio_poll *not* dispatching", i.e. in the prepare
or poll phases? In that case, the aio_poll is sleeping or might go to
sleep anytime soon, and the EventNotifier must be invoked to wake
it up.
In any other case (including if there is *no* active aio_poll at all!)
we can just wait for the next prepare phase to pick up the event (e.g. a
bottom half); the prepare phase will avoid the blocking and service the
bottom half.
Expressing the invariant with a logic formula, the broken one looked like:
!(exists(thread): in_dispatching(thread)) => !optimize
or equivalently:
!(exists(thread):
in_aio_poll(thread) && in_dispatching(thread)) => !optimize
In the correct one, the negation is in a slightly different place:
(exists(thread):
in_aio_poll(thread) && !in_dispatching(thread)) => !optimize
or equivalently:
(exists(thread): in_prepare_or_poll(thread)) => !optimize
Even if the difference boils down to moving an exclamation mark :)
the implementation is quite different. However, I think the new
one is simpler to understand.
In the old implementation, the "exists" was implemented with a boolean
value. This didn't really support well the case of multiple concurrent
event loops, but I thought that this was okay: aio_poll holds the
AioContext lock so there cannot be concurrent aio_poll invocations, and
I was just considering nested event loops. However, aio_poll _could_
indeed be concurrent with the GSource. This is why I came up with the
wrong invariant.
In the new implementation, "exists" is computed simply by counting how many
threads are in the prepare or poll phases. There are some interesting
points to consider, but the gist of the idea remains:
1) AioContext can be used through GSource as well; as mentioned in the
patch, bit 0 of the counter is reserved for the GSource.
2) the counter need not be updated for a non-blocking aio_poll, because
it won't sleep forever anyway. This is just a matter of checking
the "blocking" variable. This requires some changes to the win32
implementation, but is otherwise not too complicated.
3) as mentioned above, the new implementation will not call aio_notify
when there is *no* active aio_poll at all. The tests have to be
adjusted for this change. The calls to aio_notify in async.c are fine;
they only want to kick aio_poll out of a blocking wait, but need not
do anything if aio_poll is not running.
4) nested aio_poll: these just work with the new implementation; when
a nested event loop is invoked, the outer event loop is never in the
prepare or poll phases. The outer event loop thus has already decremented
the counter.
Reported-by: Richard W. M. Jones <rjones@redhat.com>
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Message-id: 1437487673-23740-5-git-send-email-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-07-21 17:07:51 +03:00
|
|
|
atomic_or(&ctx->notify_me, 1);
|
|
|
|
|
2014-07-09 13:53:01 +04:00
|
|
|
/* We assume there is no timeout already supplied */
|
|
|
|
*timeout = qemu_timeout_ns_to_ms(aio_compute_timeout(ctx));
|
2014-07-09 13:53:08 +04:00
|
|
|
|
|
|
|
if (aio_prepare(ctx)) {
|
|
|
|
*timeout = 0;
|
|
|
|
}
|
|
|
|
|
2014-07-09 13:53:01 +04:00
|
|
|
return *timeout == 0;
|
2012-09-24 16:57:41 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
aio_ctx_check(GSource *source)
|
|
|
|
{
|
|
|
|
AioContext *ctx = (AioContext *) source;
|
|
|
|
QEMUBH *bh;
|
|
|
|
|
AioContext: fix broken ctx->dispatching optimization
This patch rewrites the ctx->dispatching optimization, which was the cause
of some mysterious hangs that could be reproduced on aarch64 KVM only.
The hangs were indirectly caused by aio_poll() and in particular by
flash memory updates's call to blk_write(), which invokes aio_poll().
Fun stuff: they had an extremely short race window, so much that
adding all kind of tracing to either the kernel or QEMU made it
go away (a single printf made it half as reproducible).
On the plus side, the failure mode (a hang until the next keypress)
made it very easy to examine the state of the process with a debugger.
And there was a very nice reproducer from Laszlo, which failed pretty
often (more than half of the time) on any version of QEMU with a non-debug
kernel; it also failed fast, while still in the firmware. So, it could
have been worse.
For some unknown reason they happened only with virtio-scsi, but
that's not important. It's more interesting that they disappeared with
io=native, making thread-pool.c a likely suspect for where the bug arose.
thread-pool.c is also one of the few places which use bottom halves
across threads, by the way.
I hope that no other similar bugs exist, but just in case :) I am
going to describe how the successful debugging went... Since the
likely culprit was the ctx->dispatching optimization, which mostly
affects bottom halves, the first observation was that there are two
qemu_bh_schedule() invocations in the thread pool: the one in the aio
worker and the one in thread_pool_completion_bh. The latter always
causes the optimization to trigger, the former may or may not. In
order to restrict the possibilities, I introduced new functions
qemu_bh_schedule_slow() and qemu_bh_schedule_fast():
/* qemu_bh_schedule_slow: */
ctx = bh->ctx;
bh->idle = 0;
if (atomic_xchg(&bh->scheduled, 1) == 0) {
event_notifier_set(&ctx->notifier);
}
/* qemu_bh_schedule_fast: */
ctx = bh->ctx;
bh->idle = 0;
assert(ctx->dispatching);
atomic_xchg(&bh->scheduled, 1);
Notice how the atomic_xchg is still in qemu_bh_schedule_slow(). This
was already debated a few months ago, so I assumed it to be correct.
In retrospect this was a very good idea, as you'll see later.
Changing thread_pool_completion_bh() to qemu_bh_schedule_fast() didn't
trigger the assertion (as expected). Changing the worker's invocation
to qemu_bh_schedule_slow() didn't hide the bug (another assumption
which luckily held). This already limited heavily the amount of
interaction between the threads, hinting that the problematic events
must have triggered around thread_pool_completion_bh().
As mentioned early, invoking a debugger to examine the state of a
hung process was pretty easy; the iothread was always waiting on a
poll(..., -1) system call. Infinite timeouts are much rarer on x86,
and this could be the reason why the bug was never observed there.
With the buggy sequence more or less resolved to an interaction between
thread_pool_completion_bh() and poll(..., -1), my "tracing" strategy was
to just add a few qemu_clock_get_ns(QEMU_CLOCK_REALTIME) calls, hoping
that the ordering of aio_ctx_prepare(), aio_ctx_dispatch, poll() and
qemu_bh_schedule_fast() would provide some hint. The output was:
(gdb) p last_prepare
$3 = 103885451
(gdb) p last_dispatch
$4 = 103876492
(gdb) p last_poll
$5 = 115909333
(gdb) p last_schedule
$6 = 115925212
Notice how the last call to qemu_poll_ns() came after aio_ctx_dispatch().
This makes little sense unless there is an aio_poll() call involved,
and indeed with a slightly different instrumentation you can see that
there is one:
(gdb) p last_prepare
$3 = 107569679
(gdb) p last_dispatch
$4 = 107561600
(gdb) p last_aio_poll
$5 = 110671400
(gdb) p last_schedule
$6 = 110698917
So the scenario becomes clearer:
iothread VCPU thread
--------------------------------------------------------------------------
aio_ctx_prepare
aio_ctx_check
qemu_poll_ns(timeout=-1)
aio_poll
aio_dispatch
thread_pool_completion_bh
qemu_bh_schedule()
At this point bh->scheduled = 1 and the iothread has not been woken up.
The solution must be close, but this alone should not be a problem,
because the bottom half is only rescheduled to account for rare situations
(see commit 3c80ca1, thread-pool: avoid deadlock in nested aio_poll()
calls, 2014-07-15).
Introducing a third thread---a thread pool worker thread, which
also does qemu_bh_schedule()---does bring out the problematic case.
The third thread must be awakened *after* the callback is complete and
thread_pool_completion_bh has redone the whole loop, explaining the
short race window. And then this is what happens:
thread pool worker
--------------------------------------------------------------------------
<I/O completes>
qemu_bh_schedule()
Tada, bh->scheduled is already 1, so qemu_bh_schedule() does nothing
and the iothread is never woken up. This is where the bh->scheduled
optimization comes into play---it is correct, but removing it would
have masked the bug.
So, what is the bug?
Well, the question asked by the ctx->dispatching optimization ("is any
active aio_poll dispatching?") was wrong. The right question to ask
instead is "is any active aio_poll *not* dispatching", i.e. in the prepare
or poll phases? In that case, the aio_poll is sleeping or might go to
sleep anytime soon, and the EventNotifier must be invoked to wake
it up.
In any other case (including if there is *no* active aio_poll at all!)
we can just wait for the next prepare phase to pick up the event (e.g. a
bottom half); the prepare phase will avoid the blocking and service the
bottom half.
Expressing the invariant with a logic formula, the broken one looked like:
!(exists(thread): in_dispatching(thread)) => !optimize
or equivalently:
!(exists(thread):
in_aio_poll(thread) && in_dispatching(thread)) => !optimize
In the correct one, the negation is in a slightly different place:
(exists(thread):
in_aio_poll(thread) && !in_dispatching(thread)) => !optimize
or equivalently:
(exists(thread): in_prepare_or_poll(thread)) => !optimize
Even if the difference boils down to moving an exclamation mark :)
the implementation is quite different. However, I think the new
one is simpler to understand.
In the old implementation, the "exists" was implemented with a boolean
value. This didn't really support well the case of multiple concurrent
event loops, but I thought that this was okay: aio_poll holds the
AioContext lock so there cannot be concurrent aio_poll invocations, and
I was just considering nested event loops. However, aio_poll _could_
indeed be concurrent with the GSource. This is why I came up with the
wrong invariant.
In the new implementation, "exists" is computed simply by counting how many
threads are in the prepare or poll phases. There are some interesting
points to consider, but the gist of the idea remains:
1) AioContext can be used through GSource as well; as mentioned in the
patch, bit 0 of the counter is reserved for the GSource.
2) the counter need not be updated for a non-blocking aio_poll, because
it won't sleep forever anyway. This is just a matter of checking
the "blocking" variable. This requires some changes to the win32
implementation, but is otherwise not too complicated.
3) as mentioned above, the new implementation will not call aio_notify
when there is *no* active aio_poll at all. The tests have to be
adjusted for this change. The calls to aio_notify in async.c are fine;
they only want to kick aio_poll out of a blocking wait, but need not
do anything if aio_poll is not running.
4) nested aio_poll: these just work with the new implementation; when
a nested event loop is invoked, the outer event loop is never in the
prepare or poll phases. The outer event loop thus has already decremented
the counter.
Reported-by: Richard W. M. Jones <rjones@redhat.com>
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Message-id: 1437487673-23740-5-git-send-email-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-07-21 17:07:51 +03:00
|
|
|
atomic_and(&ctx->notify_me, ~1);
|
2015-07-21 17:07:53 +03:00
|
|
|
aio_notify_accept(ctx);
|
2015-07-21 17:07:52 +03:00
|
|
|
|
2012-09-24 16:57:41 +04:00
|
|
|
for (bh = ctx->first_bh; bh; bh = bh->next) {
|
|
|
|
if (!bh->deleted && bh->scheduled) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
2013-08-21 19:02:51 +04:00
|
|
|
return aio_pending(ctx) || (timerlistgroup_deadline_ns(&ctx->tlg) == 0);
|
2012-09-24 16:57:41 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
aio_ctx_dispatch(GSource *source,
|
|
|
|
GSourceFunc callback,
|
|
|
|
gpointer user_data)
|
|
|
|
{
|
|
|
|
AioContext *ctx = (AioContext *) source;
|
|
|
|
|
|
|
|
assert(callback == NULL);
|
2014-07-09 13:53:05 +04:00
|
|
|
aio_dispatch(ctx);
|
2012-09-24 16:57:41 +04:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2012-09-24 20:44:14 +04:00
|
|
|
static void
|
|
|
|
aio_ctx_finalize(GSource *source)
|
|
|
|
{
|
|
|
|
AioContext *ctx = (AioContext *) source;
|
|
|
|
|
2015-07-28 19:34:09 +03:00
|
|
|
qemu_bh_delete(ctx->notify_dummy_bh);
|
2013-03-07 16:41:47 +04:00
|
|
|
thread_pool_free(ctx->thread_pool);
|
2015-07-28 19:34:08 +03:00
|
|
|
|
|
|
|
qemu_mutex_lock(&ctx->bh_lock);
|
|
|
|
while (ctx->first_bh) {
|
|
|
|
QEMUBH *next = ctx->first_bh->next;
|
|
|
|
|
|
|
|
/* qemu_bh_delete() must have been called on BHs in this AioContext */
|
|
|
|
assert(ctx->first_bh->deleted);
|
|
|
|
|
|
|
|
g_free(ctx->first_bh);
|
|
|
|
ctx->first_bh = next;
|
|
|
|
}
|
|
|
|
qemu_mutex_unlock(&ctx->bh_lock);
|
|
|
|
|
2015-10-23 06:08:05 +03:00
|
|
|
aio_set_event_notifier(ctx, &ctx->notifier, false, NULL);
|
2012-09-24 20:44:14 +04:00
|
|
|
event_notifier_cleanup(&ctx->notifier);
|
2014-03-03 14:30:04 +04:00
|
|
|
rfifolock_destroy(&ctx->lock);
|
2013-07-16 08:28:58 +04:00
|
|
|
qemu_mutex_destroy(&ctx->bh_lock);
|
2013-08-21 19:02:49 +04:00
|
|
|
timerlistgroup_deinit(&ctx->tlg);
|
2012-09-24 20:44:14 +04:00
|
|
|
}
|
|
|
|
|
2012-09-24 16:57:41 +04:00
|
|
|
static GSourceFuncs aio_source_funcs = {
|
|
|
|
aio_ctx_prepare,
|
|
|
|
aio_ctx_check,
|
|
|
|
aio_ctx_dispatch,
|
2012-09-24 20:44:14 +04:00
|
|
|
aio_ctx_finalize
|
2012-09-24 16:57:41 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
GSource *aio_get_g_source(AioContext *ctx)
|
|
|
|
{
|
|
|
|
g_source_ref(&ctx->source);
|
|
|
|
return &ctx->source;
|
|
|
|
}
|
2012-09-13 14:28:51 +04:00
|
|
|
|
2013-03-07 16:41:47 +04:00
|
|
|
ThreadPool *aio_get_thread_pool(AioContext *ctx)
|
|
|
|
{
|
|
|
|
if (!ctx->thread_pool) {
|
|
|
|
ctx->thread_pool = thread_pool_new(ctx);
|
|
|
|
}
|
|
|
|
return ctx->thread_pool;
|
|
|
|
}
|
|
|
|
|
2012-09-24 20:44:14 +04:00
|
|
|
void aio_notify(AioContext *ctx)
|
|
|
|
{
|
AioContext: fix broken ctx->dispatching optimization
This patch rewrites the ctx->dispatching optimization, which was the cause
of some mysterious hangs that could be reproduced on aarch64 KVM only.
The hangs were indirectly caused by aio_poll() and in particular by
flash memory updates's call to blk_write(), which invokes aio_poll().
Fun stuff: they had an extremely short race window, so much that
adding all kind of tracing to either the kernel or QEMU made it
go away (a single printf made it half as reproducible).
On the plus side, the failure mode (a hang until the next keypress)
made it very easy to examine the state of the process with a debugger.
And there was a very nice reproducer from Laszlo, which failed pretty
often (more than half of the time) on any version of QEMU with a non-debug
kernel; it also failed fast, while still in the firmware. So, it could
have been worse.
For some unknown reason they happened only with virtio-scsi, but
that's not important. It's more interesting that they disappeared with
io=native, making thread-pool.c a likely suspect for where the bug arose.
thread-pool.c is also one of the few places which use bottom halves
across threads, by the way.
I hope that no other similar bugs exist, but just in case :) I am
going to describe how the successful debugging went... Since the
likely culprit was the ctx->dispatching optimization, which mostly
affects bottom halves, the first observation was that there are two
qemu_bh_schedule() invocations in the thread pool: the one in the aio
worker and the one in thread_pool_completion_bh. The latter always
causes the optimization to trigger, the former may or may not. In
order to restrict the possibilities, I introduced new functions
qemu_bh_schedule_slow() and qemu_bh_schedule_fast():
/* qemu_bh_schedule_slow: */
ctx = bh->ctx;
bh->idle = 0;
if (atomic_xchg(&bh->scheduled, 1) == 0) {
event_notifier_set(&ctx->notifier);
}
/* qemu_bh_schedule_fast: */
ctx = bh->ctx;
bh->idle = 0;
assert(ctx->dispatching);
atomic_xchg(&bh->scheduled, 1);
Notice how the atomic_xchg is still in qemu_bh_schedule_slow(). This
was already debated a few months ago, so I assumed it to be correct.
In retrospect this was a very good idea, as you'll see later.
Changing thread_pool_completion_bh() to qemu_bh_schedule_fast() didn't
trigger the assertion (as expected). Changing the worker's invocation
to qemu_bh_schedule_slow() didn't hide the bug (another assumption
which luckily held). This already limited heavily the amount of
interaction between the threads, hinting that the problematic events
must have triggered around thread_pool_completion_bh().
As mentioned early, invoking a debugger to examine the state of a
hung process was pretty easy; the iothread was always waiting on a
poll(..., -1) system call. Infinite timeouts are much rarer on x86,
and this could be the reason why the bug was never observed there.
With the buggy sequence more or less resolved to an interaction between
thread_pool_completion_bh() and poll(..., -1), my "tracing" strategy was
to just add a few qemu_clock_get_ns(QEMU_CLOCK_REALTIME) calls, hoping
that the ordering of aio_ctx_prepare(), aio_ctx_dispatch, poll() and
qemu_bh_schedule_fast() would provide some hint. The output was:
(gdb) p last_prepare
$3 = 103885451
(gdb) p last_dispatch
$4 = 103876492
(gdb) p last_poll
$5 = 115909333
(gdb) p last_schedule
$6 = 115925212
Notice how the last call to qemu_poll_ns() came after aio_ctx_dispatch().
This makes little sense unless there is an aio_poll() call involved,
and indeed with a slightly different instrumentation you can see that
there is one:
(gdb) p last_prepare
$3 = 107569679
(gdb) p last_dispatch
$4 = 107561600
(gdb) p last_aio_poll
$5 = 110671400
(gdb) p last_schedule
$6 = 110698917
So the scenario becomes clearer:
iothread VCPU thread
--------------------------------------------------------------------------
aio_ctx_prepare
aio_ctx_check
qemu_poll_ns(timeout=-1)
aio_poll
aio_dispatch
thread_pool_completion_bh
qemu_bh_schedule()
At this point bh->scheduled = 1 and the iothread has not been woken up.
The solution must be close, but this alone should not be a problem,
because the bottom half is only rescheduled to account for rare situations
(see commit 3c80ca1, thread-pool: avoid deadlock in nested aio_poll()
calls, 2014-07-15).
Introducing a third thread---a thread pool worker thread, which
also does qemu_bh_schedule()---does bring out the problematic case.
The third thread must be awakened *after* the callback is complete and
thread_pool_completion_bh has redone the whole loop, explaining the
short race window. And then this is what happens:
thread pool worker
--------------------------------------------------------------------------
<I/O completes>
qemu_bh_schedule()
Tada, bh->scheduled is already 1, so qemu_bh_schedule() does nothing
and the iothread is never woken up. This is where the bh->scheduled
optimization comes into play---it is correct, but removing it would
have masked the bug.
So, what is the bug?
Well, the question asked by the ctx->dispatching optimization ("is any
active aio_poll dispatching?") was wrong. The right question to ask
instead is "is any active aio_poll *not* dispatching", i.e. in the prepare
or poll phases? In that case, the aio_poll is sleeping or might go to
sleep anytime soon, and the EventNotifier must be invoked to wake
it up.
In any other case (including if there is *no* active aio_poll at all!)
we can just wait for the next prepare phase to pick up the event (e.g. a
bottom half); the prepare phase will avoid the blocking and service the
bottom half.
Expressing the invariant with a logic formula, the broken one looked like:
!(exists(thread): in_dispatching(thread)) => !optimize
or equivalently:
!(exists(thread):
in_aio_poll(thread) && in_dispatching(thread)) => !optimize
In the correct one, the negation is in a slightly different place:
(exists(thread):
in_aio_poll(thread) && !in_dispatching(thread)) => !optimize
or equivalently:
(exists(thread): in_prepare_or_poll(thread)) => !optimize
Even if the difference boils down to moving an exclamation mark :)
the implementation is quite different. However, I think the new
one is simpler to understand.
In the old implementation, the "exists" was implemented with a boolean
value. This didn't really support well the case of multiple concurrent
event loops, but I thought that this was okay: aio_poll holds the
AioContext lock so there cannot be concurrent aio_poll invocations, and
I was just considering nested event loops. However, aio_poll _could_
indeed be concurrent with the GSource. This is why I came up with the
wrong invariant.
In the new implementation, "exists" is computed simply by counting how many
threads are in the prepare or poll phases. There are some interesting
points to consider, but the gist of the idea remains:
1) AioContext can be used through GSource as well; as mentioned in the
patch, bit 0 of the counter is reserved for the GSource.
2) the counter need not be updated for a non-blocking aio_poll, because
it won't sleep forever anyway. This is just a matter of checking
the "blocking" variable. This requires some changes to the win32
implementation, but is otherwise not too complicated.
3) as mentioned above, the new implementation will not call aio_notify
when there is *no* active aio_poll at all. The tests have to be
adjusted for this change. The calls to aio_notify in async.c are fine;
they only want to kick aio_poll out of a blocking wait, but need not
do anything if aio_poll is not running.
4) nested aio_poll: these just work with the new implementation; when
a nested event loop is invoked, the outer event loop is never in the
prepare or poll phases. The outer event loop thus has already decremented
the counter.
Reported-by: Richard W. M. Jones <rjones@redhat.com>
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Message-id: 1437487673-23740-5-git-send-email-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-07-21 17:07:51 +03:00
|
|
|
/* Write e.g. bh->scheduled before reading ctx->notify_me. Pairs
|
|
|
|
* with atomic_or in aio_ctx_prepare or atomic_add in aio_poll.
|
|
|
|
*/
|
2014-07-07 17:18:04 +04:00
|
|
|
smp_mb();
|
AioContext: fix broken ctx->dispatching optimization
This patch rewrites the ctx->dispatching optimization, which was the cause
of some mysterious hangs that could be reproduced on aarch64 KVM only.
The hangs were indirectly caused by aio_poll() and in particular by
flash memory updates's call to blk_write(), which invokes aio_poll().
Fun stuff: they had an extremely short race window, so much that
adding all kind of tracing to either the kernel or QEMU made it
go away (a single printf made it half as reproducible).
On the plus side, the failure mode (a hang until the next keypress)
made it very easy to examine the state of the process with a debugger.
And there was a very nice reproducer from Laszlo, which failed pretty
often (more than half of the time) on any version of QEMU with a non-debug
kernel; it also failed fast, while still in the firmware. So, it could
have been worse.
For some unknown reason they happened only with virtio-scsi, but
that's not important. It's more interesting that they disappeared with
io=native, making thread-pool.c a likely suspect for where the bug arose.
thread-pool.c is also one of the few places which use bottom halves
across threads, by the way.
I hope that no other similar bugs exist, but just in case :) I am
going to describe how the successful debugging went... Since the
likely culprit was the ctx->dispatching optimization, which mostly
affects bottom halves, the first observation was that there are two
qemu_bh_schedule() invocations in the thread pool: the one in the aio
worker and the one in thread_pool_completion_bh. The latter always
causes the optimization to trigger, the former may or may not. In
order to restrict the possibilities, I introduced new functions
qemu_bh_schedule_slow() and qemu_bh_schedule_fast():
/* qemu_bh_schedule_slow: */
ctx = bh->ctx;
bh->idle = 0;
if (atomic_xchg(&bh->scheduled, 1) == 0) {
event_notifier_set(&ctx->notifier);
}
/* qemu_bh_schedule_fast: */
ctx = bh->ctx;
bh->idle = 0;
assert(ctx->dispatching);
atomic_xchg(&bh->scheduled, 1);
Notice how the atomic_xchg is still in qemu_bh_schedule_slow(). This
was already debated a few months ago, so I assumed it to be correct.
In retrospect this was a very good idea, as you'll see later.
Changing thread_pool_completion_bh() to qemu_bh_schedule_fast() didn't
trigger the assertion (as expected). Changing the worker's invocation
to qemu_bh_schedule_slow() didn't hide the bug (another assumption
which luckily held). This already limited heavily the amount of
interaction between the threads, hinting that the problematic events
must have triggered around thread_pool_completion_bh().
As mentioned early, invoking a debugger to examine the state of a
hung process was pretty easy; the iothread was always waiting on a
poll(..., -1) system call. Infinite timeouts are much rarer on x86,
and this could be the reason why the bug was never observed there.
With the buggy sequence more or less resolved to an interaction between
thread_pool_completion_bh() and poll(..., -1), my "tracing" strategy was
to just add a few qemu_clock_get_ns(QEMU_CLOCK_REALTIME) calls, hoping
that the ordering of aio_ctx_prepare(), aio_ctx_dispatch, poll() and
qemu_bh_schedule_fast() would provide some hint. The output was:
(gdb) p last_prepare
$3 = 103885451
(gdb) p last_dispatch
$4 = 103876492
(gdb) p last_poll
$5 = 115909333
(gdb) p last_schedule
$6 = 115925212
Notice how the last call to qemu_poll_ns() came after aio_ctx_dispatch().
This makes little sense unless there is an aio_poll() call involved,
and indeed with a slightly different instrumentation you can see that
there is one:
(gdb) p last_prepare
$3 = 107569679
(gdb) p last_dispatch
$4 = 107561600
(gdb) p last_aio_poll
$5 = 110671400
(gdb) p last_schedule
$6 = 110698917
So the scenario becomes clearer:
iothread VCPU thread
--------------------------------------------------------------------------
aio_ctx_prepare
aio_ctx_check
qemu_poll_ns(timeout=-1)
aio_poll
aio_dispatch
thread_pool_completion_bh
qemu_bh_schedule()
At this point bh->scheduled = 1 and the iothread has not been woken up.
The solution must be close, but this alone should not be a problem,
because the bottom half is only rescheduled to account for rare situations
(see commit 3c80ca1, thread-pool: avoid deadlock in nested aio_poll()
calls, 2014-07-15).
Introducing a third thread---a thread pool worker thread, which
also does qemu_bh_schedule()---does bring out the problematic case.
The third thread must be awakened *after* the callback is complete and
thread_pool_completion_bh has redone the whole loop, explaining the
short race window. And then this is what happens:
thread pool worker
--------------------------------------------------------------------------
<I/O completes>
qemu_bh_schedule()
Tada, bh->scheduled is already 1, so qemu_bh_schedule() does nothing
and the iothread is never woken up. This is where the bh->scheduled
optimization comes into play---it is correct, but removing it would
have masked the bug.
So, what is the bug?
Well, the question asked by the ctx->dispatching optimization ("is any
active aio_poll dispatching?") was wrong. The right question to ask
instead is "is any active aio_poll *not* dispatching", i.e. in the prepare
or poll phases? In that case, the aio_poll is sleeping or might go to
sleep anytime soon, and the EventNotifier must be invoked to wake
it up.
In any other case (including if there is *no* active aio_poll at all!)
we can just wait for the next prepare phase to pick up the event (e.g. a
bottom half); the prepare phase will avoid the blocking and service the
bottom half.
Expressing the invariant with a logic formula, the broken one looked like:
!(exists(thread): in_dispatching(thread)) => !optimize
or equivalently:
!(exists(thread):
in_aio_poll(thread) && in_dispatching(thread)) => !optimize
In the correct one, the negation is in a slightly different place:
(exists(thread):
in_aio_poll(thread) && !in_dispatching(thread)) => !optimize
or equivalently:
(exists(thread): in_prepare_or_poll(thread)) => !optimize
Even if the difference boils down to moving an exclamation mark :)
the implementation is quite different. However, I think the new
one is simpler to understand.
In the old implementation, the "exists" was implemented with a boolean
value. This didn't really support well the case of multiple concurrent
event loops, but I thought that this was okay: aio_poll holds the
AioContext lock so there cannot be concurrent aio_poll invocations, and
I was just considering nested event loops. However, aio_poll _could_
indeed be concurrent with the GSource. This is why I came up with the
wrong invariant.
In the new implementation, "exists" is computed simply by counting how many
threads are in the prepare or poll phases. There are some interesting
points to consider, but the gist of the idea remains:
1) AioContext can be used through GSource as well; as mentioned in the
patch, bit 0 of the counter is reserved for the GSource.
2) the counter need not be updated for a non-blocking aio_poll, because
it won't sleep forever anyway. This is just a matter of checking
the "blocking" variable. This requires some changes to the win32
implementation, but is otherwise not too complicated.
3) as mentioned above, the new implementation will not call aio_notify
when there is *no* active aio_poll at all. The tests have to be
adjusted for this change. The calls to aio_notify in async.c are fine;
they only want to kick aio_poll out of a blocking wait, but need not
do anything if aio_poll is not running.
4) nested aio_poll: these just work with the new implementation; when
a nested event loop is invoked, the outer event loop is never in the
prepare or poll phases. The outer event loop thus has already decremented
the counter.
Reported-by: Richard W. M. Jones <rjones@redhat.com>
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Message-id: 1437487673-23740-5-git-send-email-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-07-21 17:07:51 +03:00
|
|
|
if (ctx->notify_me) {
|
2014-07-07 17:18:04 +04:00
|
|
|
event_notifier_set(&ctx->notifier);
|
2015-07-21 17:07:53 +03:00
|
|
|
atomic_mb_set(&ctx->notified, true);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void aio_notify_accept(AioContext *ctx)
|
|
|
|
{
|
|
|
|
if (atomic_xchg(&ctx->notified, false)) {
|
|
|
|
event_notifier_test_and_clear(&ctx->notifier);
|
2014-07-07 17:18:04 +04:00
|
|
|
}
|
2012-09-24 20:44:14 +04:00
|
|
|
}
|
|
|
|
|
2013-08-21 19:02:50 +04:00
|
|
|
static void aio_timerlist_notify(void *opaque)
|
|
|
|
{
|
|
|
|
aio_notify(opaque);
|
|
|
|
}
|
|
|
|
|
2015-06-03 12:15:33 +03:00
|
|
|
static void aio_rfifolock_cb(void *opaque)
|
|
|
|
{
|
2015-07-28 19:34:09 +03:00
|
|
|
AioContext *ctx = opaque;
|
|
|
|
|
2015-06-03 12:15:33 +03:00
|
|
|
/* Kick owner thread in case they are blocked in aio_poll() */
|
2015-07-28 19:34:09 +03:00
|
|
|
qemu_bh_schedule(ctx->notify_dummy_bh);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void notify_dummy_bh(void *opaque)
|
|
|
|
{
|
|
|
|
/* Do nothing, we were invoked just to force the event loop to iterate */
|
2015-06-03 12:15:33 +03:00
|
|
|
}
|
|
|
|
|
2015-07-21 17:07:52 +03:00
|
|
|
static void event_notifier_dummy_cb(EventNotifier *e)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2014-09-18 15:30:49 +04:00
|
|
|
AioContext *aio_context_new(Error **errp)
|
2012-10-30 02:45:23 +04:00
|
|
|
{
|
2014-09-18 15:30:49 +04:00
|
|
|
int ret;
|
2012-09-24 20:44:14 +04:00
|
|
|
AioContext *ctx;
|
2015-10-30 07:06:28 +03:00
|
|
|
Error *local_err = NULL;
|
|
|
|
|
2012-09-24 20:44:14 +04:00
|
|
|
ctx = (AioContext *) g_source_new(&aio_source_funcs, sizeof(AioContext));
|
2015-10-30 07:06:28 +03:00
|
|
|
aio_context_setup(ctx, &local_err);
|
|
|
|
if (local_err) {
|
|
|
|
error_propagate(errp, local_err);
|
|
|
|
goto fail;
|
|
|
|
}
|
2014-09-18 15:30:49 +04:00
|
|
|
ret = event_notifier_init(&ctx->notifier, false);
|
|
|
|
if (ret < 0) {
|
|
|
|
error_setg_errno(errp, -ret, "Failed to initialize event notifier");
|
2015-10-30 07:06:28 +03:00
|
|
|
goto fail;
|
2014-09-18 15:30:49 +04:00
|
|
|
}
|
2014-12-17 18:09:58 +03:00
|
|
|
g_source_set_can_recurse(&ctx->source, true);
|
2014-09-18 15:30:49 +04:00
|
|
|
aio_set_event_notifier(ctx, &ctx->notifier,
|
2015-10-23 06:08:05 +03:00
|
|
|
false,
|
2014-09-18 15:30:49 +04:00
|
|
|
(EventNotifierHandler *)
|
2015-07-21 17:07:52 +03:00
|
|
|
event_notifier_dummy_cb);
|
2013-03-07 16:41:47 +04:00
|
|
|
ctx->thread_pool = NULL;
|
2013-07-16 08:28:58 +04:00
|
|
|
qemu_mutex_init(&ctx->bh_lock);
|
2015-06-03 12:15:33 +03:00
|
|
|
rfifolock_init(&ctx->lock, aio_rfifolock_cb, ctx);
|
2013-08-21 19:02:50 +04:00
|
|
|
timerlistgroup_init(&ctx->tlg, aio_timerlist_notify, ctx);
|
2012-09-24 20:44:14 +04:00
|
|
|
|
2015-07-28 19:34:09 +03:00
|
|
|
ctx->notify_dummy_bh = aio_bh_new(ctx, notify_dummy_bh, NULL);
|
|
|
|
|
2012-09-24 20:44:14 +04:00
|
|
|
return ctx;
|
2015-10-30 07:06:28 +03:00
|
|
|
fail:
|
|
|
|
g_source_destroy(&ctx->source);
|
|
|
|
return NULL;
|
2012-09-24 16:57:41 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void aio_context_ref(AioContext *ctx)
|
|
|
|
{
|
|
|
|
g_source_ref(&ctx->source);
|
|
|
|
}
|
|
|
|
|
|
|
|
void aio_context_unref(AioContext *ctx)
|
|
|
|
{
|
|
|
|
g_source_unref(&ctx->source);
|
2012-10-30 02:45:23 +04:00
|
|
|
}
|
2014-03-03 14:30:04 +04:00
|
|
|
|
|
|
|
void aio_context_acquire(AioContext *ctx)
|
|
|
|
{
|
|
|
|
rfifolock_lock(&ctx->lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
void aio_context_release(AioContext *ctx)
|
|
|
|
{
|
|
|
|
rfifolock_unlock(&ctx->lock);
|
|
|
|
}
|