From: Fiona Ebner <f.ebner@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [PATCH qemu-server v5 3/4] hotplug: factor out cleanup of disk devices
Date: Tue, 3 Nov 2026 16:29:35 +0100 [thread overview]
Message-ID: <6a23ef58-afdd-4da6-8b2e-ee3dfb4262f5@proxmox.com> (raw)
In-Reply-To: <b972e0be-c342-4d55-8abc-f36b8876da9f@proxmox.com>
Am 03.11.26 um 4:11 PM schrieb Dominik Csapak:
> On 11/3/26 3:41 PM, Fiona Ebner wrote:
>> Am 03.11.26 um 2:01 PM schrieb Dominik Csapak:
>>> On 11/3/26 12:06 PM, Fiona Ebner wrote:
>>>> Am 30.10.26 um 11:11 AM schrieb Dominik Csapak:
>>>>
>>>>> + my ($conf, $vmid, $deviceid, $device, $timeout, $noerr) = @_;
>>>>> +
>>>>> + my $warn_or_die = sub {
>>>>> + my ($sub) = @_;
>>>>> + eval { $sub->(); };
>>>>> + if (my $err = $@) {
>>>>> + die $err if !$noerr;
>>>>> + warn $err;
>>>>> + }
>>>>> + };
>>>>
>>>> Rather than having this with $noerr, just make the callers use our
>>>> common eval + warn pattern. That would improve readability below and on
>>>> the call sites (reading a "1" there won't tell you how it relates to
>>>> error behavior without looking it up).
>>>>
>>>
>>> If i understand you correctly this would change the semantic though?
>>>
>>> now with noerr = 1, every cleanup here runs regardless if it fails or
>>> not.
>>>
>>> if i just check on the call site, the first error skips the cleanup
>>> of the rest?
>>
>> Right, but isn't that actually what we want? The objects depend on each
>> other, so we should only delete them in order. We do/should not fail if
>> an object is already deleted. Otherwise your next patch would introduce
>> a bunch of additional warnings in most error cases when attempting to
>> remove stuff that was never added.
>
> well it might happen that devicedelverify is failing even though
> it's actually removed if i understand https://bugzilla.proxmox.com/
> show_bug.cgi?id=8273 correctly?
>
> so we might want to continue anyway? they shouldn't be removable
> if something depends on it, but trying in any case works around
> some timeouts i think...
If devicedelverify() reports that it failed, we should assume so. It
would just be luck if the subsequent command works because of timing
reasons.
We should make sure a subsequent cleanup removes the left-overs, but
that is independent.
I would rather bump the timeout for the relevant 'query-pci' command
(not too much if not inside a worker context) to avoid the failure in
the first place.
next prev parent reply other threads:[~2026-11-03 15:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 10:04 [PATCH qemu-server v5 0/4] hotplug: improve and fix cleanup/error handling Dominik Csapak
2026-10-30 10:04 ` [PATCH qemu-server v5 1/4] hotplug: scsi: only keep controller if a disk on it is still present Dominik Csapak
2026-10-30 10:04 ` [PATCH qemu-server v5 2/4] hotplug: remove iothread with virtio-scsi controller together Dominik Csapak
2026-10-30 10:04 ` [PATCH qemu-server v5 3/4] hotplug: factor out cleanup of disk devices Dominik Csapak
2026-11-03 11:06 ` Fiona Ebner
2026-11-03 13:01 ` Dominik Csapak
2026-11-03 14:41 ` Fiona Ebner
2026-11-03 15:11 ` Dominik Csapak
2026-11-03 15:29 ` Fiona Ebner [this message]
2026-11-03 14:26 ` Dominik Csapak
2026-10-30 10:04 ` [PATCH qemu-server v5 4/4] hotplug: clean up disk devices/objects if adding them failed Dominik Csapak
2026-11-03 10:54 ` applied: (subset) [PATCH qemu-server v5 0/4] hotplug: improve and fix cleanup/error handling Fiona Ebner
2026-11-04 6:56 ` superseded: " 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=6a23ef58-afdd-4da6-8b2e-ee3dfb4262f5@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=d.csapak@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.