[PATCH common/storage 0/3] fix #8286: do not hold inherited locks in volume cleanup workers

["Michael Köppl" <m.koeppl@proxmox.com>]

Destroying a VM through the API with a disk on an LVM storage with
saferemove=1 leaves its VMID locked until the wipe of the disk is done.
The imgdel worker is forked while the qmdestroy worker holds the
config lock and inherits the locked file handle. The worker keeps the
lock held after the qmdestroy worker exited. Re-creating a VM with the
same VMID fails with a lock timeout in the meantime.

This series tries to keep the fix targeted, since closing all inherited
file descriptors in fork_worker() has a lot of regression
potential [0]. An opt-in helper is added in pve-common to close the
lock handles a forked child inherited from its ancestors. This call is
added to vdisk_free before running the cleanup workers of the
respective plugin. At the moment, this affects only the LVM plugin,
which only operates on volumes that are not referenced anymore and
takes the storage lock on its own where needed. Thus, this also
expects external plugins with cleanup workers to not rely on the
cleanup worker holding the caller's lock.

The last patch does the same for the cleanup workers the LVM plugin
forks itself for snapshot rollback and deletion and for failed
imports. It is not needed to fix the bug, but these workers inherit
their caller's locks too. For example, restoring a VM over an existing
one with qcow2 snapshots on LVM deletes the snapshots of kept disks
under the config lock. Since the rollback cleanup worker then no
longer holds the guest migration lock, the patch also adds a rollback
check that the volume replaced by a previous rollback is not still
being wiped. Otherwise, the rollback would fail after the guest was
already locked for it.

Tested on a single node by destroying a VM with a disk on an LVM
storage with saferemove through the API and re-creating it right after
the destroy task finished, while the wipe was still running.

The last patch was tested by restoring a backup through the API over
an existing VM with a qcow2 snapshot on an LVM storage with saferemove
and a disk excluded from the backup. The config of the VM could be
changed while the kept disk was still being wiped. Both cleanup workers
finished successfully.

[0] https://bugzilla.proxmox.com/show_bug.cgi?id=8286


common:

Michael Köppl (1):
  tools: lock file: add helper to close inherited lock handles

 src/PVE/Tools.pm  | 23 +++++++++++++++-----
 test/lock_file.pl | 54 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 72 insertions(+), 5 deletions(-)


storage:

Michael Köppl (2):
  fix #8286: vdisk free: do not hold inherited locks in cleanup worker
  lvm plugin: do not hold inherited locks in cleanup workers

 src/PVE/Storage.pm           | 10 +++++++++-
 src/PVE/Storage/LVMPlugin.pm | 16 +++++++++++++++-
 2 files changed, 24 insertions(+), 2 deletions(-)


Summary over all repositories:
  4 files changed, 96 insertions(+), 7 deletions(-)

-- 
Generated by murpp 0.12.1