From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <m.heiserer@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 6F32A906A6
for <pve-devel@lists.proxmox.com>; Thu, 22 Sep 2022 12:14:33 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 5154E7571
for <pve-devel@lists.proxmox.com>; Thu, 22 Sep 2022 12:14:33 +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>; Thu, 22 Sep 2022 12:14:32 +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 7C24744253
for <pve-devel@lists.proxmox.com>; Thu, 22 Sep 2022 12:14:32 +0200 (CEST)
Message-ID: <fe353a40-fc02-38a7-1fcc-0537b6debbd3@proxmox.com>
Date: Thu, 22 Sep 2022 12:14:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.13.0
Content-Language: en-US
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Dominik Csapak <d.csapak@proxmox.com>
References: <20220921124911.3224970-1-d.csapak@proxmox.com>
<20220921124911.3224970-3-d.csapak@proxmox.com>
From: Matthias Heiserer <m.heiserer@proxmox.com>
In-Reply-To: <20220921124911.3224970-3-d.csapak@proxmox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results: 0
AWL 1.671 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
NICE_REPLY_A -3.702 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 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: Thu, 22 Sep 2022 10:14:33 -0000
On 21.09.2022 14:49, 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 | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/qmeventd/qmeventd.c b/qmeventd/qmeventd.c
> index e9ff5b3..de5efd0 100644
> --- a/qmeventd/qmeventd.c
> +++ b/qmeventd/qmeventd.c
> @@ -415,6 +415,25 @@ cleanup_qemu_client(struct Client *client)
> }
> }
>
> +static void
> +remove_cleanup_data(void *ptr, void *client_ptr) {
Not that it really matters, but is there a reason we don't use
remove_cleanup_data(struct CleanupData *ptr, struct Client *client_ptr)
and let the caller deal with types?
> + struct CleanupData *data = (struct CleanupData *)ptr;
> + struct Client *client = (struct Client *)client_ptr;
> +
> + if (data->pid == client->pid) {
> + forced_cleanups = g_slist_remove(forced_cleanups, ptr);
> + free(ptr);
> + }
> +}
> + > +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, remove_cleanup_data, client);
that is, here `(void (*)(void*, void*)) remove_cleanup_data`. Seems a
bit cleaner to me.
> + }
> +}
> +
> void
> cleanup_client(struct Client *client)
> {
> @@ -441,6 +460,7 @@ cleanup_client(struct Client *client)
> break;
> }
>
> + remove_from_forced_cleanup(client);
> free(client);
> }
>