> On 25 Feb 2026, at 10:59 PM, Peter Xu <[email protected]> wrote:
>
> Hi, Ani,
>
> On Wed, Feb 25, 2026 at 09:19:40AM +0530, Ani Sinha wrote:
>> Currently the code that adds a migration blocker does not check if the same
>> blocker already exists. Return an EEXIST error code if there is an attempt to
>> add the same migration blocker again. This way the same migration blocker
>> will
>> not get added twice.
>
> Could you help explain why it will inject two identical errors in the first
> place, and why the caller cannot make sure it won't be injected twice?
Likely due to a bug in the code. For example if the init function that adds the
blocker is called again and the caller does not handle the second init call
properly.
This came up as a part of the coco reset work where migration blockers are
added in init methods. They need not be added again when init methods are again
called during the reset process. The caller can handle it of course but adding
a check further down the call stack makes things more robust.
>
> Thanks,
>
>>
>> Suggested-by: Prasad Pandit <[email protected]>
>> Signed-off-by: Ani Sinha <[email protected]>
>> ---
>> migration/migration.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/migration/migration.c b/migration/migration.c
>> index a5b0465ed3..1eb75fb7fb 100644
>> --- a/migration/migration.c
>> +++ b/migration/migration.c
>> @@ -1702,6 +1702,10 @@ static int add_blockers(Error **reasonp, unsigned
>> modes, Error **errp)
>> {
>> for (MigMode mode = 0; mode < MIG_MODE__MAX; mode++) {
>> if (modes & BIT(mode)) {
>> + if (g_slist_index(migration_blockers[mode],
>> + *reasonp) >= 0) {
>> + return -EEXIST;
>> + }
>> migration_blockers[mode] =
>> g_slist_prepend(migration_blockers[mode],
>> *reasonp);
>> }
>> --
>> 2.42.0
>>
>
> --
> Peter Xu
