[pve-devel] [PATCH qemu-server v2 2/3] qmeventd: cancel 'forced cleanup' when normal cleanup succeeds

[Dominik Csapak]

On 9/23/22 10:31, Wolfgang Bumiller wrote:
> On Thu, Sep 22, 2022 at 04:19:34PM +0200, Dominik Csapak wrote:
>> instead of always sending a SIGKILL to the target pid.
>> It was not that much of a problem since the timeout previously was 5
>> seconds and we used pifds where possible, thus the chance of killing the
>> wrong process was rather slim.
>>
>> Now we increased the timeout to 60s which makes the race a bit more likely
>> (when not using pidfds), so remove it from the 'forced_cleanups' list when
>> the normal cleanup succeeds.
>>
>> Signed-off-by: Dominik Csapak <d.csapak at proxmox.com>
>> ---
>>   qmeventd/qmeventd.c | 17 +++++++++++++++++
>>   1 file changed, 17 insertions(+)
>>
>> diff --git a/qmeventd/qmeventd.c b/qmeventd/qmeventd.c
>> index 46bc7eb..eebc19d 100644
>> --- a/qmeventd/qmeventd.c
>> +++ b/qmeventd/qmeventd.c
>> @@ -416,6 +416,22 @@ cleanup_qemu_client(struct Client *client)
>>       }
>>   }
>>   
>> +static void
>> +remove_cleanup_data(struct CleanupData *data, struct Client *client) {
>> +    if (data->pid == client->pid) {
>> +	forced_cleanups = g_slist_remove(forced_cleanups, data);
>> +	free(data);
>> +    }
>> +}
>> +
>> +static void
>> +remove_from_forced_cleanup(struct Client *client) {
>> +    if (g_slist_length(forced_cleanups) > 0) {
>> +	VERBOSE_PRINT("removing %s from forced cleanups\n", client->qemu.vmid);
>> +	g_slist_foreach(forced_cleanups, (GFunc)remove_cleanup_data, client);
> 
> Foreach + remove feels awkward to me. Sure, it's a linked list and
> should be fine™, but I don't like the lack of documentation of
> interactions here as a non-glib user. (I mean, eg. for C++ iterator
> invalidation is *usually* documented...)

just to clarify: it's documented in glibs docs[0]:
 > It is safe for func to remove the element from list, but it must not modify any part of the list 
after that element.

> 
> Can't we just give `struct Client` a `struct CleanupData` pointer and
> call `g_slist_remove` right here without the iteration?
> 
> Or better yet, your previous idea of dropping `CleanupData` sounds
> better.
> We should be able to just add `struct Client*` to the list, after all,
> according to the glib docs `g_slist_remove` should simply leave the list
> unchanged if the data is not part of the list, so when we free up the
> `Client` we could even call `g_slist_remove` unconditionally (though
> we'll know whether it's in there by having a timeout set then...)
> 
> (or use `g_slist_find_custom`)

sounds good to me

> 
>> +    }
>> +}
>> +
>>   void
>>   cleanup_client(struct Client *client)
>>   {
>> @@ -442,6 +458,7 @@ cleanup_client(struct Client *client)
>>   	    break;
>>       }
>>   
>> +    remove_from_forced_cleanup(client);
>>       free(client);
>>   }
>>   
>> -- 
>> 2.30.2

0: https://docs.gtk.org/glib/type_func.SList.foreach.html