On 3/12/26 5:16 AM, Trieu Huynh wrote:
migrate_add_blocker() can fail (e.g. if migration is already in
progress), in which case it returns a negative value and populates
its errp argument with the reason.
The previous code ignored the return value, leaving state
inconsistent on failure. Fix this by:
- Passing a local Error ** so failure details can be reported.
- Checking the return value; on failure, report the error, free the
migration_blocker Error object, and return NULL to the caller.
Resolves: CID 1645470
Signed-off-by: Trieu Huynh <[email protected]>
---
plugins/api-system.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
While the description makes sense, how would it happen in real world?
Plugins usually will request time control on startup (so no migration is
happening). In all cases, plugin who want to control time will have no
other choice than abort.
Maybe we could simply assert that migrate_add_blocker succeeded in this
context.
Regards,
Pierrick
