On 13.09.18 14:52, Kevin Wolf wrote: > Block jobs claim in .drained_poll() that they are in a quiescent state > as soon as job->deferred_to_main_loop is true. This is obviously wrong, > they still have a completion BH to run. We only get away with this > because commit 91af091f923 added an unconditional aio_poll(false) to the > drain functions, but this is bypassing the regular drain mechanisms. > > However, just removing this and telling that the job is still active > doesn't work either: The completion callbacks themselves call drain > functions (directly, or indirectly with bdrv_reopen), so they would > deadlock then. > > As a better lie, tell that the job is active as long as the BH is > pending, but falsely call it quiescent from the point in the BH when the > completion callback is called. At this point, nested drain calls won't > deadlock because they ignore the job, and outer drains will wait for the > job to really reach a quiescent state because the callback is already > running.
...because it's running in the main loop, so it's impossible for another drain to run there concurrently. I suppose. At least that's what makes this patch make sense to me. > Signed-off-by: Kevin Wolf <kw...@redhat.com> > --- > include/qemu/job.h | 3 +++ > blockjob.c | 2 +- > job.c | 11 ++++++++++- > 3 files changed, 14 insertions(+), 2 deletions(-) Reviewed-by: Max Reitz <mre...@redhat.com>
signature.asc
Description: OpenPGP digital signature
