From nobody Mon Feb 2 07:31:21 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass(p=reject dis=none) header.from=lists.libvirt.org ARC-Seal: i=1; a=rsa-sha256; t=1769443779; cv=none; d=zohomail.com; s=zohoarc; b=kgF79EdEb+c/Z3cGshWA0+WK1SfmI9un2x8CN9pFuECs7V9d2raGzuWOUF1tSprVM5eRTvl4938/+j83+ltRAxQg9b80HGbppFdBBeHbLWpnh40S/TrgIvm/FAk4rnOKMA7OSIXaJ031mudELy8ydgSy9JfCgHzrUaH5CWpJAiY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1769443779; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Owner:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Reply-To:References:Subject:Subject:To:To:Message-Id:Cc; bh=3ak0/INwpiV52gR+1ZqOf/GI9N/+sI6q1+Q9RjOqk88=; b=IX95h9qrvjv3CXrfXWYs8MNcJ7rs2Fc5ziZZ+gk8rZArYgXmdvn+sWgQXb/hAZMIDAN/2/OeUxpVosvB7cVOOIxNq7ra3NC8S0ZiYoMT8dyXyqEOIT6mfpaB4NT8x7TjopMqQI6hzffGq0zBp79Zk9hvYLjkG0rXLwGsGaYOpSA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1769443779018673.0993909725679; Mon, 26 Jan 2026 08:09:39 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 993) id 9945C419A3; Mon, 26 Jan 2026 11:09:36 -0500 (EST) Received: from [172.19.199.3] (lists.libvirt.org [8.43.85.245]) by lists.libvirt.org (Postfix) with ESMTP id 987CA43E44; Mon, 26 Jan 2026 11:07:09 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 993) id EA96E4194C; Mon, 26 Jan 2026 11:07:03 -0500 (EST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (3072 bits) server-digest SHA256) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 17DA14194C for ; Mon, 26 Jan 2026 11:07:03 -0500 (EST) Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-387-KHH2EdZ3MJ6QQAaZ38v5lA-1; Mon, 26 Jan 2026 11:07:00 -0500 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9D5141944EBB for ; Mon, 26 Jan 2026 16:06:59 +0000 (UTC) Received: from speedmetal.lan (unknown [10.45.242.3]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E79E318001D5 for ; Mon, 26 Jan 2026 16:06:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED,SPF_PASS autolearn=unavailable autolearn_force=no version=4.0.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769443622; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3ak0/INwpiV52gR+1ZqOf/GI9N/+sI6q1+Q9RjOqk88=; b=hK6+iwlbVtOTQ3V9sY89gtyhww5Jw6UHU1Hfbb5jI84xTzgospC3kIJ1hpR+wfCAGOsdg8 40OBb+aItxOrMarQaSsHO5/+C8JqYzu6XIzchFl9UapKBfc8Z+qRQH4OBy/MzSG+y/E0IV 2bGc3+95XnNtfLk7jM3Jh97A/+wK3n0= X-MC-Unique: KHH2EdZ3MJ6QQAaZ38v5lA-1 X-Mimecast-MFC-AGG-ID: KHH2EdZ3MJ6QQAaZ38v5lA_1769443619 To: devel@lists.libvirt.org Subject: [PATCH v2 3/5] qemuSnapshotDiskHasBackingDisk: Use proper 'max_depth' when calling 'virStorageSourceGetMetadata' Date: Mon, 26 Jan 2026 17:06:51 +0100 Message-ID: <7b10280a27e9425192810ff05620e60cf1852c2a.1769443445.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: huVGNowjzk0mcrJzYtwPJETaFKKQDvONGhDHLcAN37M_1769443619 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Message-ID-Hash: MBX3QKWIIOWK2BZEF3HMY2ORF6DOIIWT X-Message-ID-Hash: MBX3QKWIIOWK2BZEF3HMY2ORF6DOIIWT X-MailFrom: pkrempa@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.lists.libvirt.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: Peter Krempa via Devel Reply-To: Peter Krempa X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1769443781384154100 Content-Type: text/plain; charset="utf-8" From: Peter Krempa The 'max_depth' argument of 'virStorageSourceGetMetadata' doesn't just limit how far the function goes but also fails completely if the chain is deeper than the passed value. In 'qemuSnapshotDiskHasBackingDisk' we only care about finding the backing image, so just one level below, the passed path, but due to the above setting '1' as max_depth will make the function simply fail every time. Extract and reuse QEMU_DOMAIN_STORAGE_SOURCE_CHAIN_MAX_DEPTH as the detection depth. While '200' layers is overkill for this code, we also start a full qemu instance just to delete an snapshot so this doens't matter and still protects from self-referential images. Signed-off-by: Peter Krempa --- src/qemu/qemu_domain.c | 2 -- src/qemu/qemu_domain.h | 1 + src/qemu/qemu_snapshot.c | 4 +++- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index ac56fc7cb4..486a0e7913 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -6297,8 +6297,6 @@ qemuDomainStorageAlias(const char *device, int depth) } -#define QEMU_DOMAIN_STORAGE_SOURCE_CHAIN_MAX_DEPTH 200 - /** * qemuDomainStorageSourceValidateDepth: * @src: storage source chain to validate diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index 3396f929fd..b9bb338682 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -706,6 +706,7 @@ int qemuDomainCheckDiskStartupPolicy(virQEMUDriver *dri= ver, size_t diskIndex, bool cold_boot); +#define QEMU_DOMAIN_STORAGE_SOURCE_CHAIN_MAX_DEPTH 200 int qemuDomainStorageSourceValidateDepth(virStorageSource *src, int add, const char *diskdst); diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c index 19bb6f8b37..1628c33865 100644 --- a/src/qemu/qemu_snapshot.c +++ b/src/qemu/qemu_snapshot.c @@ -3145,7 +3145,9 @@ qemuSnapshotDiskHasBackingDisk(void *payload, NULL, &uid, &gid); if (!disk->src->backingStore) - ignore_value(virStorageSourceGetMetadata(disk->src, uid, gid, = 1, false)); + ignore_value(virStorageSourceGetMetadata(disk->src, uid, gid, + QEMU_DOMAIN_STORAGE_S= OURCE_CHAIN_MAX_DEPTH, + false)); if (disk->src->backingStore && virStorageSourceIsSameLocation(disk->src->backingStore, iterda= ta->diskSrc)) { --=20 2.52.0