* Wei Yang (richardw.y...@linux.intel.com) wrote:
> On Tue, Oct 08, 2019 at 05:02:02PM +0100, Dr. David Alan Gilbert wrote:
> >* Wei Yang (richardw.y...@linux.intel.com) wrote:
> >> postcopy_ram_incoming_cleanup() does cleanup for
> >> postcopy_ram_incoming_setup(), while the setup happens only after
> >> migration enters LISTEN state.
> >>
> >> This means there is nothing to cleanup when migration is still ADVISE
> >> state.
> >>
> >> Signed-off-by: Wei Yang <richardw.y...@linux.intel.com>
> >> ---
> >> migration/migration.c | 1 -
> >> 1 file changed, 1 deletion(-)
> >>
> >> diff --git a/migration/migration.c b/migration/migration.c
> >> index 5f7e4d15e9..34d5e66f06 100644
> >> --- a/migration/migration.c
> >> +++ b/migration/migration.c
> >> @@ -461,7 +461,6 @@ static void process_incoming_migration_co(void *opaque)
> >> * but managed to complete within the precopy period, we can
> >> use
> >> * the normal exit.
> >> */
> >> - postcopy_ram_incoming_cleanup(mis);
> >> } else if (ret >= 0) {
> >> /*
> >> * Postcopy was started, cleanup should happen at the end of
> >> the
> >
> >I think that misses the cleanup of mlock that corresponds to the
> >munlockall in postcopy_ram_supported_by_host - that's called very early
> >on; I think in the advise stage.
> >
>
> Thanks you are right.
>
> BTW, do we need to check enable_mlock when calling munlockall() in
> postcopy_ram_supported_by_host() ?
I don't think so; it does an extra munlock in that case when nothing
should be locked anyway, no harm.
Dave
> >Dave
> >
> >> --
> >> 2.17.1
> >>
> >--
> >Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>
> --
> Wei Yang
> Help you, Help me
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
