]> rtime.felk.cvut.cz Git - lisovros/qemu_apohw.git/commit
block: wait for job callback in block_job_cancel_sync
authorPaolo Bonzini <pbonzini@redhat.com>
Tue, 8 May 2012 14:51:46 +0000 (16:51 +0200)
committerKevin Wolf <kwolf@redhat.com>
Thu, 10 May 2012 08:32:12 +0000 (10:32 +0200)
commitfa4478d5c8b74a5f0c8b93cc00590ec007be5016
tree7dd064b6cceff7e91f6e43ac67aa8ca99d5c93dc
parent4513eafe928ff47486f4167c28d364c72b5ff7e3
block: wait for job callback in block_job_cancel_sync

The limitation on not having I/O after cancellation cannot really be
kept.  Even streaming has a very small race window where you could
cancel a job and have it report completion.  If this window is hit,
bdrv_change_backing_file() will yield and possibly cause accesses to
dangling pointers etc.

So, let's just assume that we cannot know exactly what will happen
after the coroutine has set busy to false.  We can set a very lax
condition:

- if we cancel the job, the coroutine won't set it to false again
(and hence will not call co_sleep_ns again).

- block_job_cancel_sync will wait for the coroutine to exit, which
pretty much ensures no race.

Instead, we track the coroutine that executes the job and put very
strict conditions on what to do while it is quiescent (busy = false).
First of all, the coroutine must never set busy = false while the job
has been cancelled.  Second, the coroutine can be reentered arbitrarily
while it is quiescent, so you cannot really do anything but co_sleep_ns at
that time.  This condition is obeyed by the block_job_sleep_ns function.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
block.c
block/stream.c
block_int.h