From: Jakob-Tobias Winter <tobias@stuttgart.de>
To: tobias@linuxdingsda.de, pbs-devel@lists.proxmox.com
Cc: Jakob-Tobias Winter <tobias@stuttgart.de>
Subject: [PATCH proxmox-backup] tape: virtual drive: fix endless recursion in changer status
Date: Mon, 9 Nov 2026 22:59:50 +0100 [thread overview]
Message-ID: <20261109215950.903491-1-tobias@stuttgart.de> (raw)
The virtual tape drive, which exists for tests and debugging only, also
acts as its own changer and reports every virtual tape in its directory
as a slot. To build that status it asked for the list of online media,
but got the generic variant of that list, which is derived from the
changer status. The two called each other until the stack overflowed, so
every operation that needs the changer status of a virtual drive, like
loading or unloading a tape, crashed the process.
Use the list of tapes in the directory of the drive instead, as it was
intended, for the status and for loading a tape from a slot.
Signed-off-by: Jakob-Tobias Winter <tobias@stuttgart.de>
---
The recursion has been there since 46a1863f8 ("tape: improve MediaChange
trait").
Reproducer, with a virtual drive 'vtape' in tape.cfg and an empty file
'tape-demo1.json' in its directory:
proxmox-backup-debug api create /tape/drive/vtape/load-slot \
--source-slot 1
Tested with debug builds of current master and of 4.2.8, calling the API
in-process (PROXMOX_DEBUG_API_CODE=1): the call aborts with a stack
overflow without the patch and loads the tape with it.
src/tape/drive/virtual_tape.rs | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/tape/drive/virtual_tape.rs b/src/tape/drive/virtual_tape.rs
index a17916bab..b2febaed5 100644
--- a/src/tape/drive/virtual_tape.rs
+++ b/src/tape/drive/virtual_tape.rs
@@ -499,7 +499,7 @@ impl MediaChange for VirtualTapeHandle {
// slot-assignment here.
let mut slots = Vec::new();
- let label_texts = self.online_media_label_texts()?;
+ let label_texts = VirtualTapeHandle::online_media_label_texts(self)?;
let max_slots = label_texts.len().div_ceil(8) * 8;
for i in 0..max_slots {
@@ -535,7 +535,7 @@ impl MediaChange for VirtualTapeHandle {
bail!("invalid slot ID {}", slot);
}
- let label_texts = self.online_media_label_texts()?;
+ let label_texts = VirtualTapeHandle::online_media_label_texts(self)?;
if slot > label_texts.len() as u64 {
bail!("slot {} is empty", slot);
--
2.53.0
reply other threads:[~2026-11-09 22:07 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20261109215950.903491-1-tobias@stuttgart.de \
--to=tobias@stuttgart.de \
--cc=pbs-devel@lists.proxmox.com \
--cc=tobias@linuxdingsda.de \
/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