all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Dominik Csapak <d.csapak@proxmox.com>
To: Matthias Heiserer <m.heiserer@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server 2/3] qmeventd: cancel 'forced cleanup' when normal cleanup succeeds
Date: Thu, 22 Sep 2022 13:37:57 +0200	[thread overview]
Message-ID: <d800cf42-329a-e4ff-a2b6-3cfdcdfb6689@proxmox.com> (raw)
In-Reply-To: <fe353a40-fc02-38a7-1fcc-0537b6debbd3@proxmox.com>

On 9/22/22 12:14, Matthias Heiserer wrote:
> 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);
>>   }
> 

i just kept the style we use for the existing call to *_foreach.

my guess is that the intention was to keep the function close to what glib defines
(although that uses 'gpointer'). doing as you suggested introduces a big
cast that is confusing to read IMHO (for people not that familiar with c at least ;) )
that could be solved with casting to 'GFunc' (not sure if that's considered good style?)
but in the end, i don't have strong feeling either way




  reply	other threads:[~2022-09-22 11:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21 12:49 [pve-devel] [PATCH qemu-server 0/3] qmeventd: improve shutdown behaviour Dominik Csapak
2022-09-21 12:49 ` [pve-devel] [PATCH qemu-server 1/3] qmeventd: rework 'forced_cleanup' handling and set timeout to 60s Dominik Csapak
     [not found]   ` <<20220921124911.3224970-2-d.csapak@proxmox.com>
2022-09-22  8:24     ` Fabian Grünbichler
2022-09-22 11:31       ` Dominik Csapak
2022-09-22 12:01         ` Wolfgang Bumiller
2022-09-22 12:22           ` Dominik Csapak
2022-09-22 12:46             ` Wolfgang Bumiller
2022-09-22 11:51   ` Thomas Lamprecht
2022-09-21 12:49 ` [pve-devel] [PATCH qemu-server 2/3] qmeventd: cancel 'forced cleanup' when normal cleanup succeeds Dominik Csapak
2022-09-22 10:14   ` Matthias Heiserer
2022-09-22 11:37     ` Dominik Csapak [this message]
2022-09-23  7:58       ` Wolfgang Bumiller
2022-09-21 12:49 ` [pve-devel] [PATCH qemu-server 3/3] qmeventd: send QMP 'quit' command instead of SIGTERM Dominik Csapak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d800cf42-329a-e4ff-a2b6-3cfdcdfb6689@proxmox.com \
    --to=d.csapak@proxmox.com \
    --cc=m.heiserer@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal