From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <f.ebner@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 10CB6E20C
for <pve-devel@lists.proxmox.com>; Mon, 25 Sep 2023 10:46:14 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id E72DD1C9B5
for <pve-devel@lists.proxmox.com>; Mon, 25 Sep 2023 10:46:13 +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>; Mon, 25 Sep 2023 10:46:13 +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 1D99148D3C
for <pve-devel@lists.proxmox.com>; Mon, 25 Sep 2023 10:46:13 +0200 (CEST)
Message-ID: <1d6ae212-9b16-ab4d-e025-07664c35d06a@proxmox.com>
Date: Mon, 25 Sep 2023 10:46:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.15.0
To: Dominik Csapak <d.csapak@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
References: <20230912091617.26590-1-f.ebner@proxmox.com>
<6ff59a25-0401-41c4-8352-379bc0bafeb3@proxmox.com>
Content-Language: en-US
From: Fiona Ebner <f.ebner@proxmox.com>
In-Reply-To: <6ff59a25-0401-41c4-8352-379bc0bafeb3@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.657 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DMARC_MISSING 0.1 Missing DMARC policy
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
NICE_REPLY_A -1.473 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 1/3] fix #2816: restore: remove
timeout when allocating disks
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: Mon, 25 Sep 2023 08:46:14 -0000
Am 20.09.23 um 13:23 schrieb Dominik Csapak:
> comment inline:
Feel free to cut out irrelevant parts in the reply ;)
> On 9/12/23 11:16, Fiona Ebner wrote:
>> @@ -7483,14 +7483,11 @@ sub restore_vma_archive {
>> $devinfo->{$devname} = { size => $size, dev_id => $dev_id };
>> } elsif ($line =~ m/^CTIME: /) {
>> # we correctly received the vma config, so we can disable
>> - # the timeout now for disk allocation (set to 10 minutes, so
>> - # that we always timeout if something goes wrong)
>> - alarm(600);
>> + # the timeout now for disk allocation
I would interpret this comment about disabling of the timeout to be
talking about the short 5 second timeout for reading the config.
>> + alarm($oldtimeout || 0);
>> + $oldtimeout = undef;
>
>
> this part looks wrong to me, because AFAIU you want to disable the timeout
> (by canceling the alarm), but what you do here is to set it to $oldtimeout
> if that was set before?
>
> i guess what we want to do here is:
>
> ----
> alarm(0);
> <... do stuff ...>
> alarm($oldtimeout || 0);
> $oldtimeout = undef;
> ----
>
> ?
Hmm, I see what you mean. But I'd argue that it's unexpected to disable
the outer timeout for the full duration of the allocation from a
caller's perspective.
sub in_a_hurry {
alarm(120); # outer/old timeout
restore_vma_archive(...);
}
With the code before the patch, it could take up to 5 + 600 + 120
seconds to hit the outer timeout, with your suggestion up to 5 +
potentially unlimited + 120 seconds, with patched code up to 5 + 120
seconds. Since there currently are no callers setting an outer timeout,
the patch doesn't make the situation worse.
We could even make the calculation more complicated and have the timeout
always be hit within 120 seconds in the example above, but not sure if
worth it.
AFAICS, we do similar "delay" of the outer timeout in e.g.
run_with_timeout(), where it can also take up to $inner_timeout +
$outer_timeout seconds to hit the outer timeout.