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
