On Wed, Jan 07, 2026 at 04:31:54PM +0530, Prasad Pandit wrote: > 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?
IMHO you can work on top of that series directly, then when you repost you can add "Based-on:" mentioning that series. > > > 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. Having a new status introduced only partially to the subsystem in separate patch and especially only backporting that partial patch sounds more risky and wrong. Let's try our best to make sure it won't break anything but implement the status properly altogether. Thanks, -- Peter Xu
