From nobody Sun Feb 8 16:11:34 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 63.128.21.124 as permitted sender) client-ip=63.128.21.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 63.128.21.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.zohomail.com with SMTPS id 1613406621956123.17281672790114; Mon, 15 Feb 2021 08:30:21 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-426-AapcJiEYM1SYbV_hNsSXKA-1; Mon, 15 Feb 2021 11:30:18 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BB19F801975; Mon, 15 Feb 2021 16:30:12 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9330B60BE2; Mon, 15 Feb 2021 16:30:12 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 51BBC18095CB; Mon, 15 Feb 2021 16:30:12 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 11FGTl72026810 for ; Mon, 15 Feb 2021 11:29:48 -0500 Received: by smtp.corp.redhat.com (Postfix) id F0B685C233; Mon, 15 Feb 2021 16:29:47 +0000 (UTC) Received: from localhost.localdomain (unknown [10.40.193.96]) by smtp.corp.redhat.com (Postfix) with ESMTP id 73B775C541 for ; Mon, 15 Feb 2021 16:29:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613406620; h=from:from:sender:sender: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:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=hRDasXX05801LQUo2QAdgpaDz4T+0HyHbaanAe3huac=; b=flOkg37R/h0pNhV+Yn5fzU5giY9q4zc/UF+48JPr0XMcn36AxGywfYlBc5TYBnmS8jBYxn QCFMi00Ax/sWhkmbdrLKJMZImCDe+mBeg1Qwtsg8E2kMbSVpgE96E+zQlzuGHSl1cYV4vE yJKf2f5vvQo0/l/eluqKXuoxbLi7Fw4= X-MC-Unique: AapcJiEYM1SYbV_hNsSXKA-1 From: Michal Privoznik To: libvir-list@redhat.com Subject: [PATCH 3/3] qemu: Don't lie about @ndevAlias when translating FSInfo Date: Mon, 15 Feb 2021 17:29:34 +0100 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: libvir-list@redhat.com X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" When virDomainGetFSInfo() is called over a QEMU/KVM domain it results into calling of 'guest-get-fsinfo' guest agent command to which it replies with info on guest (mounted) filesystems. When filling return structure we also try to do basic lookup and translate guest agent provided disk address into disk target (as seen in domain XML). This can of course fail - guest can have variety of disks not recorded in domain XML (iSCSI, scsi_debug, NFS to name a few). If that's the case, a debug message is logged and no disk target is added into the return structure. However, due to the way our code is written the caller is led to believe that the target was added into the structure. This may lead to a situation where the array of disk targets (strings) contains NULL. But our RPC structure says the array contains only non-NULL strings. This results in somewhat 'cryptic' (at least to users) error message: error: Unable to get filesystem information error: Unable to encode message payload Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=3D1919783 Signed-off-by: Michal Privoznik Reviewed-by: J=C3=A1n Tomko --- src/qemu/qemu_driver.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index d30cf75b73..0da9264b49 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -18932,9 +18932,8 @@ qemuAgentFSInfoToPublic(qemuAgentFSInfoPtr agent, =20 if (agent->disks) ret->devAlias =3D g_new0(char *, agent->ndisks); - ret->ndevAlias =3D agent->ndisks; =20 - for (i =3D 0; i < ret->ndevAlias; i++) { + for (i =3D 0; i < agent->ndisks; i++) { qemuAgentDiskAddressPtr agentdisk =3D agent->disks[i]; virDomainDiskDefPtr diskDef; =20 @@ -18945,7 +18944,7 @@ qemuAgentFSInfoToPublic(qemuAgentFSInfoPtr agent, agentdisk->target, agentdisk->unit); if (diskDef !=3D NULL) - ret->devAlias[i] =3D g_strdup(diskDef->dst); + ret->devAlias[ret->ndevAlias++] =3D g_strdup(diskDef->dst); else VIR_DEBUG("Missing target name for '%s'.", ret->mountpoint); } --=20 2.26.2