On 11/29/2017 04:25 AM, Paolo Bonzini wrote:
This reverts the effects of commit 4afeffc857 ("blockjob: do not allow coroutine double entry or entry-after-completion", 2017-11-21)This fixed the symptom of a bug rather than the root cause. Canceling the wait on a sleeping blockjob coroutine is generally fine, we just need to make it work correctly across AioContexts. To do so, use a QEMUTimer that calls block_job_enter. Use a mutex to ensure that block_job_enter synchronizes correctly with block_job_sleep_ns. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> ---
I'm a bit late in reviewing; just pointing out that:
@@ -807,14 +848,8 @@ void block_job_sleep_ns(BlockJob *job, int64_t ns) return; }- /* We need to leave job->busy set here, because when we have- * put a coroutine to 'sleep', we have scheduled it to run in - * the future. We cannot enter that same coroutine again before - * it wakes and runs, otherwise we risk double-entry or entry after - * completion. */ if (!block_job_should_pause(job)) { - co_aio_sleep_ns(blk_get_aio_context(job->blk), - QEMU_CLOCK_REALTIME, ns); + block_job_do_yield(job, qemu_clock_get_ns(QEMU_CLOCK_REALTIME) + ns);
This conflicts slightly with https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg01681.html that simplifies co_aio_sleep_ns. Are we left with any callers of co_aio_sleep_ns() that can use anything other than QEMU_CLOCK_REALTIME, or can that also be simplified?
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
