diff options
author | Peter Xu <peterx@redhat.com> | 2020-10-21 17:27:20 -0400 |
---|---|---|
committer | Dr. David Alan Gilbert <dgilbert@redhat.com> | 2020-10-26 16:15:04 +0000 |
commit | d246ea5039fd6d5344becd0943fcbb7f8e6bbfe7 (patch) | |
tree | 0442790f727155b1d870ceb57e0882ecafa37b0b /migration/block-dirty-bitmap.c | |
parent | 0c26781c0937324d175b8105bc96ccce778d9760 (diff) |
migration/postcopy: Release fd before going into 'postcopy-pause'
Logically below race could trigger with the old code:
test program migration thread
------------ ----------------
wait_until('postcopy-pause')
postcopy_pause()
set_state('postcopy-pause')
do_postcopy_recover()
arm s->to_dst_file with new fd
release s->to_dst_file [1]
Here [1] could have released the just-installed recoverying channel. Then the
migration could hang without really resuming.
Instead, it should be very safe to release the fd before setting the state into
'postcopy-pause', because there's no reason for any other thread to touch it
during 'postcopy-active'.
Dave reported a very rare postcopy recovery hang that the migration-test
program waited for the migration to complete in migrate_postcopy_complete().
We do suspect it's the same thing that we're gonna fix here. Hard to tell.
However since we've noticed this, fix this irrelevant of the hang report.
Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Cc: Juan Quintela <quintela@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20201021212721.440373-6-peterx@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Diffstat (limited to 'migration/block-dirty-bitmap.c')
0 files changed, 0 insertions, 0 deletions