public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Michael Köppl" <m.koeppl@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [PATCH storage 2/3] fix #8286: vdisk free: do not hold inherited locks in cleanup worker
Date: Thu,  5 Nov 2026 17:36:36 +0100	[thread overview]
Message-ID: <20261105163637.1318072-3-m.koeppl@proxmox.com> (raw)
In-Reply-To: <20261105163637.1318072-1-m.koeppl@proxmox.com>

vdisk_free() forks the cleanup worker of a volume (e.g. for wiping LVs
on LVM storages with saferemove), while the caller often still holds the
guest config lock. The worker inherits the locked handle and keeps the
lock held until the cleanup is done. For example, after destroying a VM
through the API, re-creating a VM with the same VMID fails with a lock
timeout until the wipe has finished.

The cleanup workers in the LVM plugin only operate on volumes that are
not referenced anymore. The plugin's implementation takes the lock on
its own where needed, so close the inherited lock handles when the
worker starts. This applies to the cleanup worker of any plugin, which
must not rely on the cleanup worker holding the caller's lock.

Signed-off-by: Michael Köppl <m.koeppl@proxmox.com>
---

Notes:
    I'm not quite sure about this one. I understand that it breaks this
    behavior for existing external plugins, but I'm not sure it's something
    they should rely on in the first place. An alternative to this would be
    to put the cleanup call into the LVM plugin's cleanup worker
    specifically, which would also require every plugin to implement this
    in its cleanup worker. Could perhaps also be a sensible approach for
    now to have the call in the LVM plugin specifically and move it to
    vdisk_free for PVE 10. I mostly decided on this version for now because
    of Fabian's comment on the Bugzilla ticket.

 src/PVE/Storage.pm | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/PVE/Storage.pm b/src/PVE/Storage.pm
index d660cfc4..4cec7c31 100755
--- a/src/PVE/Storage.pm
+++ b/src/PVE/Storage.pm
@@ -1222,7 +1222,15 @@ sub vdisk_free {
     my $rpcenv = PVE::RPCEnvironment::get();
     my $authuser = $rpcenv->get_user();
 
-    $rpcenv->fork_worker('imgdel', undef, $authuser, $cleanup_worker);
+    $rpcenv->fork_worker(
+        'imgdel',
+        undef,
+        $authuser,
+        sub {
+            PVE::Tools::close_inherited_lock_handles();
+            $cleanup_worker->(@_);
+        },
+    );
 }
 
 sub vdisk_list {
-- 
2.47.3





  parent reply	other threads:[~2026-11-05 16:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05 16:36 [PATCH common/storage 0/3] fix #8286: do not hold inherited locks in volume cleanup workers Michael Köppl
2026-11-05 16:36 ` [PATCH common 1/3] tools: lock file: add helper to close inherited lock handles Michael Köppl
2026-11-05 16:36 ` Michael Köppl [this message]
2026-11-05 16:36 ` [PATCH storage 3/3] lvm plugin: do not hold inherited locks in cleanup workers Michael Köppl

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=20261105163637.1318072-3-m.koeppl@proxmox.com \
    --to=m.koeppl@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal