Re: [PATCH 2/6] migration: Kick postcopy threads on cancel

[Peter Xu <peterx@redhat.com>]

On Wed, Dec 04, 2024 at 05:40:17PM -0300, Fabiano Rosas wrote:
> To be clear, I'm not arguing against cancel. I'm just pointing out that
> it's silly because it's just like pressing C-c in the shell in the
> middle of something. What's the expected end state? Completely
> unspecified. I don't find it at all "elegant" that we treat cancel like
> error and just let the code carry on stumbling and exit
> eventually. Because then we have this C-c arriving at random moments in
> the middle of stuff. The way we do "exiting" in multifd is way more
> maintainable. If that flag is set, then let's exit, otherwise everything
> should work.

If taking the example of C-c, then "migration during postcopy" is exactly
"TASK_UNINTERRUPTIBLE".. :) IOW, "hanging death" the C-c is the correct and
expected behavior for UNINTERRUPTIBLE tasks.

[...]

> > 'yank' is intended to be forceful, letting you get out of bad situations
> > that would otherwise require you to kill the entire QEMU process, but
> > still with possible associated risk data loss to the QEMU backends.
> 
> For migration specifically I don't see much difference. Yank must leave
> QEMU in a usable state enough for a second migration to succeed,
> otherwise it's useless.

Side note: when I said (in the other reply) that we should remove yank
support on migration, I meant, we should probably deprecate that (and then
remove it).

-- 
Peter Xu