From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <d.csapak@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by lists.proxmox.com (Postfix) with ESMTPS id 7247390BEA
for <pve-devel@lists.proxmox.com>; Fri, 23 Sep 2022 10:43:32 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 3412621E7E
for <pve-devel@lists.proxmox.com>; Fri, 23 Sep 2022 10:43:02 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
[94.136.29.106])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by firstgate.proxmox.com (Proxmox) with ESMTPS
for <pve-devel@lists.proxmox.com>; Fri, 23 Sep 2022 10:43:01 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
by proxmox-new.maurer-it.com (Proxmox) with ESMTP id D004D44295;
Fri, 23 Sep 2022 10:43:00 +0200 (CEST)
Message-ID: <501307c2-f2a6-0ff9-7c5c-cccc80c4c352@proxmox.com>
Date: Fri, 23 Sep 2022 10:42:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101
Thunderbird/105.0
Content-Language: en-US
To: Wolfgang Bumiller <w.bumiller@proxmox.com>
Cc: pve-devel@lists.proxmox.com
References: <20220922141935.653179-1-d.csapak@proxmox.com>
<20220922141935.653179-3-d.csapak@proxmox.com>
<20220923083137.evlm3264dakglezg@wobu-vie.proxmox.com>
From: Dominik Csapak <d.csapak@proxmox.com>
In-Reply-To: <20220923083137.evlm3264dakglezg@wobu-vie.proxmox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results: 0
AWL 1.017 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
KAM_SHORT 0.001 Use of a URL Shortener for very short URL
NICE_REPLY_A -1.893 Looks like a legit reply (A)
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
Subject: Re: [pve-devel] [PATCH qemu-server v2 2/3] qmeventd: cancel 'forced
cleanup' when normal cleanup succeeds
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Fri, 23 Sep 2022 08:43:32 -0000
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@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