On Tue, Nov 28, 2017 at 04:43:48PM +0100, Kevin Wolf wrote:
> This reverts commit 4afeffc8572f40d8844b946a30c00b10da4442b1.
>
> This fixed the symptom of a bug rather than the root cause. Waking up a
> sleeping coroutine is generally fine, we just need to make it work
> correctly across AioContexts, which we'll do in a minute.
>
> Signed-off-by: Kevin Wolf <kw...@redhat.com>
Reviewed-by: Jeff Cody <jc...@redhat.com>
> ---
> include/block/blockjob_int.h | 3 +--
> blockjob.c | 7 ++-----
> 2 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/include/block/blockjob_int.h b/include/block/blockjob_int.h
> index 43f3be2965..f13ad05c0d 100644
> --- a/include/block/blockjob_int.h
> +++ b/include/block/blockjob_int.h
> @@ -143,8 +143,7 @@ void *block_job_create(const char *job_id, const
> BlockJobDriver *driver,
> * @ns: How many nanoseconds to stop for.
> *
> * Put the job to sleep (assuming that it wasn't canceled) for @ns
> - * nanoseconds. Canceling the job will not interrupt the wait, so the
> - * cancel will not process until the coroutine wakes up.
> + * nanoseconds. Canceling the job will interrupt the wait immediately.
> */
> void block_job_sleep_ns(BlockJob *job, QEMUClockType type, int64_t ns);
>
> diff --git a/blockjob.c b/blockjob.c
> index ff9a614531..3a0c49137e 100644
> --- a/blockjob.c
> +++ b/blockjob.c
> @@ -797,14 +797,11 @@ void block_job_sleep_ns(BlockJob *job, QEMUClockType
> type, 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. */
> + job->busy = false;
> if (!block_job_should_pause(job)) {
> co_aio_sleep_ns(blk_get_aio_context(job->blk), type, ns);
> }
> + job->busy = true;
>
> block_job_pause_point(job);
> }
> --
> 2.13.6
>
