On Tue, 6 Jan 2026 at 20:53, Peter Xu <[email protected]> wrote: > Yes, something like this would be more than welcomed, thanks. You can > provide a simplified version in the commit log when repost.
* Okay. > Note that I'm not reading carefully into each of them, because we have > concurrent changes from Fabiano recently, essentially it'll change when > migration_cleanup() will be used in above examples: > > https://lore.kernel.org/r/[email protected] > > So we'll need to be careful landing these two changes. > Considering that the other series was close to landing, IMHO it might be > good idea to have your patch (when reposted) based on that series. Please > have a look. * Yes, I see it is changing the same code areas. I'll wait for Fabiano's series to merge upstream. Will it happen this week? @Fabiano Rosas? > I still think FAILING isn't such a huge change so it needs to be split into > multiple patches. It's a new status and we need to review every spot of > FAILED status change, in which case one patch is very well self contained. > > Even in a backport I think we should backport all relevant changes about > FAILING when necessary. We should not backport part of it, causing FAILING > status to behave different over different paths. * Adding a new interim state to the .json file is not going to break anything. But other places where we start using it via a bulk change might break things we don't know. So far we've only tested it in a live migration use case. We have not run snapshots (bg_migration_iteration()) OR the same host migration use case. Hopefully it might work fine there, without any breakages. Thank you. --- - Prasad
