From nobody Mon Sep 16 20:04:38 2024 Delivered-To: importer@patchew.org Received-SPF: none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; spf=none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1706637546241405.0446708550236; Tue, 30 Jan 2024 09:59:06 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 996) id 23B471E5E; Tue, 30 Jan 2024 12:59:05 -0500 (EST) Received: from lists.libvirt.org.85.43.8.in-addr.arpa (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id 8EF951890; Tue, 30 Jan 2024 12:12:24 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 996) id EB6E31C3D; Tue, 30 Jan 2024 12:10:40 -0500 (EST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id EDD981C86 for ; Tue, 30 Jan 2024 12:08:44 -0500 (EST) Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-177-SSOTL_N9M3-AdchJE7pw6A-1; Tue, 30 Jan 2024 12:08:41 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (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 mimecast-mx02.redhat.com (Postfix) with ESMTPS id 49A3D1C05139 for ; Tue, 30 Jan 2024 17:08:41 +0000 (UTC) Received: from speedmetal.redhat.com (unknown [10.45.242.16]) by smtp.corp.redhat.com (Postfix) with ESMTP id B77242166B31 for ; Tue, 30 Jan 2024 17:08:40 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.4 X-MC-Unique: SSOTL_N9M3-AdchJE7pw6A-1 From: Peter Krempa To: devel@lists.libvirt.org Subject: [PATCH 29/31] virPCIVPDParseVPDLargeResourceFields: Refactor return logic Date: Tue, 30 Jan 2024 18:08:07 +0100 Message-ID: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Message-ID-Hash: 6Q72KIZ2A5BOEAZ63D2IVDZV2Z3MYGMI X-Message-ID-Hash: 6Q72KIZ2A5BOEAZ63D2IVDZV2Z3MYGMI X-MailFrom: pkrempa@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-config-2; header-match-config-3; header-match-devel.lists.libvirt.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.2 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZM-MESSAGEID: 1706637547551100001 Rewrite the conditions after exiting the parser so that they are easier to understand. This partially decreases the granularity of "error" messages as they are not strictly necessary albeit for debugging. As it was already observed in this code the logic itself often does something else than the comment claims, thus the code logic is preserved. Changes: - any case when not all data was processed is agregated together and gets a common "error" message - absence of 'checksum' field is checked separately - helper variables are removed as they are no longer needed Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- src/util/virpcivpd.c | 32 +++++++++++++------------------- 1 file changed, 13 insertions(+), 19 deletions(-) diff --git a/src/util/virpcivpd.c b/src/util/virpcivpd.c index 60e520c46f..be19f7b747 100644 --- a/src/util/virpcivpd.c +++ b/src/util/virpcivpd.c @@ -415,10 +415,7 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, ui= nt16_t resPos, uint16_t re g_autofree uint8_t *buf =3D g_malloc0(PCI_VPD_MAX_FIELD_SIZE + 1); uint16_t fieldDataLen =3D 0, bytesToRead =3D 0; uint16_t fieldPos =3D resPos; - bool hasChecksum =3D false; - bool hasRW =3D false; - bool endReached =3D false; /* Note the equal sign - fields may have a zero length in which case t= hey will * just occupy 3 header bytes. In the in case of the RW field this may= mean that @@ -507,7 +504,9 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, uin= t16_t resPos, uint16_t re case VIR_PCI_VPD_RESOURCE_FIELD_VALUE_FORMAT_RDWR: /* Skip the read-write space since it is used for indicati= on only. */ - hasRW =3D true; + /* The lack of RW is allowed on purpose in the read-write = section since some vendors + * violate the PCI/PCIe specs and do not include it, howev= er, this does not prevent parsing + * of valid data. */ goto done; case VIR_PCI_VPD_RESOURCE_FIELD_VALUE_FORMAT_RESVD: @@ -531,6 +530,7 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, uin= t16_t resPos, uint16_t re if (!res->rw) res->rw =3D virPCIVPDResourceRWNew(); } + /* The field format, keyword and value are determined. Attempt to = update the resource. */ virPCIVPDResourceUpdateKeyword(res, readOnly, fieldKeyword, fieldV= alue); } @@ -538,27 +538,21 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, u= int16_t resPos, uint16_t re done: /* May have exited the loop prematurely in case RV or RW were encounte= red and * they were not the last fields in the section. */ - endReached =3D (fieldPos >=3D resPos + resDataLen); - if (readOnly && !(hasChecksum && endReached)) { - VIR_DEBUG("VPD-R does not contain the mandatory RV field as the la= st field"); + if ((fieldPos < resPos + resDataLen)) { + /* unparsed data still present */ + VIR_DEBUG("PCI VPD data parsing failed"); + return false; + } + + if (readOnly && !hasChecksum) { + VIR_DEBUG("VPD-R does not contain the mandatory checksum"); return false; - } else if (!readOnly && !endReached) { - /* The lack of RW is allowed on purpose in the read-write section = since some vendors - * violate the PCI/PCIe specs and do not include it, however, this= does not prevent parsing - * of valid data. If the RW is present, however, we make sure it i= s the last field in - * the read-write section. */ - if (hasRW) { - VIR_DEBUG("VPD-W section parsing ended prematurely (RW is not = the last field)."); - return false; - } else { - VIR_DEBUG("VPD-W section parsing ended prematurely."); - return false; - } } return true; } + /** * virPCIVPDParseVPDLargeResourceString: * @vpdFileFd: A file descriptor associated with a file containing PCI dev= ice VPD. --=20 2.43.0 _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org