From nobody Sun May 19 13:14:54 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) client-ip=170.10.129.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 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=fail(p=none dis=none) header.from=canonical.com ARC-Seal: i=1; a=rsa-sha256; t=1664274261; cv=none; d=zohomail.com; s=zohoarc; b=anxaGSNlD5IgIzY6FTeDKbTTkGAVGxJLNteqQW1CHj+/y4BlyfTk0eQU4pb5FilSx03i1vBJAhMbTkGR8RXD3U2bZtBTBqCnrbN4px/p67iMtWgsaskeY50iioUBwAkMj5GOMA9gxJHQt1a6WRKV9PJoS11DP3J+J/uhyTN4qkM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1664274261; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=yWNX/ZfY89JFlR1nSJ1bPfVjw2sKiqT+1d+QZg38VuE=; b=Uv0bL10zthWkq3FI9CzOxK0x9QQJ9G5waif9R68Ct73wbzO4L4vZHXc3+q8nkkFvXUFODsOkLbMpxVTno9E1GGvv7AtUJxObgFSff63ZJppKx5L/xQjvxvIfXWxEw9DG2D7/YXK0Qvran53bhj6JSgcFPg0M0QPUK/Zs79lSmCw= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=fail header.from= (p=none dis=none) Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.zohomail.com with SMTPS id 166427426169015.68694762416942; Tue, 27 Sep 2022 03:24:21 -0700 (PDT) Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-171-wR6HjeBtPGOJqcxc5QYPQQ-1; Tue, 27 Sep 2022 06:24:17 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id BFD5C1C08971; Tue, 27 Sep 2022 10:24:13 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0FB3040C2064; Tue, 27 Sep 2022 10:24:12 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id E3DCC1946A45; Tue, 27 Sep 2022 10:24:11 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 398751946586 for ; Tue, 27 Sep 2022 10:24:11 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 17520C15BA8; Tue, 27 Sep 2022 10:24:11 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast01.extmail.prod.ext.rdu2.redhat.com [10.11.55.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0FFC2C15BA4 for ; Tue, 27 Sep 2022 10:24:11 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E634A85A5A6 for ; Tue, 27 Sep 2022 10:24:10 +0000 (UTC) Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-616--3PYKiuTOo-dvjupbl4z5g-1; Tue, 27 Sep 2022 06:24:06 -0400 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (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 smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 910463F82C for ; Tue, 27 Sep 2022 10:17:48 +0000 (UTC) Received: by mail-wr1-f70.google.com with SMTP id g19-20020adfa493000000b0022a2ee64216so2011257wrb.14 for ; Tue, 27 Sep 2022 03:17:48 -0700 (PDT) Received: from localhost.localdomain ([2a02:6d40:3a4b:da00:2040:a1d0:f764:459c]) by smtp.gmail.com with ESMTPSA id ba11-20020a0560001c0b00b0022a9246c853sm1410704wrb.41.2022.09.27.03.17.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Sep 2022 03:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664274260; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=yWNX/ZfY89JFlR1nSJ1bPfVjw2sKiqT+1d+QZg38VuE=; b=Exne5C5JTH6z2arQQsDcafILxbbreNhc00I2Ea0iVFuaziiQw9FQqmNn/OqLKYpBl70LZQ HBTAOFIIyXSE2fWvz3cLAaGHYB5mwASIMAkozq12WfXqVr30VGdRb1sG+avKJDSJRrVWr9 zvWRzKMrITHXrZrvZUDM+SqiJtnw1pw= X-MC-Unique: wR6HjeBtPGOJqcxc5QYPQQ-1 X-Original-To: libvir-list@listman.corp.redhat.com X-MC-Unique: -3PYKiuTOo-dvjupbl4z5g-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date; bh=Wb4kCdGkF1XJDmcEd9OSwfsr/CuCN9t/QQOhuqwpHFg=; b=5hUMj4Kgj7i4kru3/YuIwVQ+2SrCULSk5LFPid+GHsKSW4XfMKrIvbc+8W5qwEF8Jp bii3R7NT4esRbJxHQf3W00a6OTehQ6PKVt9Mah0JbIp92I9yK/jmoW7ZtdE0vprcL4HR EeTEhxJMnHeHcaszUvpqhcbm8r3qmb49Y5Hj6ElEHFXBaZ63RxC88UPbpI3WkxCwadEn eP2QVVIGc+AOn+xzfGjKGP1yC/qu50WhEh1tt1SgD2RVd/sarhmiT67FCbgpJoUPvIgE d+ADGUsKNI/STNTToLtCyTU8VNTZhX+Z23RIWvD967HMYx2XtejfK4v/hsqZ0CdY2qAd Ry1g== X-Gm-Message-State: ACrzQf0LEioDd6cm5sroI6nP9UZm/Rm9Ozl7kOSLQl+AVuBqXW1kNNGa erV9HQkDf2eILMFFXidPphKNGjN/MhAqYfqyYozOA4q+/Hmy0Dld80yLj+wfUDXXBYs7+jboJnn /Cje51T2mJ1P0inr1HsvHa1iMk8c1CONHtg== X-Received: by 2002:a5d:584d:0:b0:22b:229:7582 with SMTP id i13-20020a5d584d000000b0022b02297582mr16627088wrf.211.1664273867822; Tue, 27 Sep 2022 03:17:47 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7Vi8XccmXW3wX5rMIKrvP9gzi5sKetsBECK0xtue1xuCdsSH71dRffhlfUuYKMI4Qdu//cwg== X-Received: by 2002:a5d:584d:0:b0:22b:229:7582 with SMTP id i13-20020a5d584d000000b0022b02297582mr16627069wrf.211.1664273867498; Tue, 27 Sep 2022 03:17:47 -0700 (PDT) From: christian.ehrhardt@canonical.com To: libvir-list@redhat.com Subject: [PATCH] virpcivpd: reduce errors in log due to invalid VPD Date: Tue, 27 Sep 2022 12:17:41 +0200 Message-Id: <20220927101741.3467399-1-christian.ehrhardt@canonical.com> MIME-Version: 1.0 X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Dmitrii Shcherbakov , Christian Ehrhardt Errors-To: libvir-list-bounces@redhat.com Sender: "libvir-list" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1664274264191100001 Content-Type: text/plain; charset="utf-8"; x-default="true" From: Christian Ehrhardt Sadly some devices provide invalid VPD data even with fully updated firmware. Former hardning like 600f580d "PCI VPD: Skip fields with invalid values" have already helped for those to some extent. But if one happens to have such a device installed in the system, despite all other things working properly the log potentially flooded with messages like: internal error: The keyword is not comprised only of uppercase ASCII letters or digits internal error: A field data length violates the resource length boundary. The user can't do anything about it to change that, they will be there on any libvirt restart and potentially distract from other more important issues. Since the vpd decoding is implemented rather resilient (if parsing fails all goes on fine, the respective device just has no VPD data populated eventually) we can lower those from virReportError(VIR_ERR_INTERNAL_ERROR to just VIR_INFO. If needed for debugging people can set the level accordingly, but otherwise we would no more fill the logs with errors without a strong reason. Fixes: https://launchpad.net/bugs/1990949 Signed-off-by: Christian Ehrhardt Reviewed-by: Michal Privoznik --- src/util/virpcivpd.c | 47 +++++++++++++++----------------------------- 1 file changed, 16 insertions(+), 31 deletions(-) diff --git a/src/util/virpcivpd.c b/src/util/virpcivpd.c index 4ba4fea237..39557c7347 100644 --- a/src/util/virpcivpd.c +++ b/src/util/virpcivpd.c @@ -62,12 +62,11 @@ virPCIVPDResourceGetKeywordPrefix(const char *keyword) =20 /* Keywords must have a length of 2 bytes. */ if (strlen(keyword) !=3D 2) { - virReportError(VIR_ERR_INTERNAL_ERROR, _("The keyword length is no= t 2 bytes: %s"), keyword); + VIR_INFO("The keyword length is not 2 bytes: %s", keyword); return NULL; } else if (!(virPCIVPDResourceIsUpperOrNumber(keyword[0]) && virPCIVPDResourceIsUpperOrNumber(keyword[1]))) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("The keyword is not comprised only of uppercase A= SCII letters or digits")); + VIR_INFO("The keyword is not comprised only of uppercase ASCII let= ters or digits"); return NULL; } /* Special-case the system-specific keywords since they share the "Y" = prefix with "YA". */ @@ -328,19 +327,16 @@ virPCIVPDResourceUpdateKeyword(virPCIVPDResource *res= , const bool readOnly, const char *const keyword, const char *cons= t value) { if (!res) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Cannot update the resource: a NULL resource poin= ter has been provided.")); + VIR_INFO("Cannot update the resource: a NULL resource pointer has = been provided."); return false; } else if (!keyword) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Cannot update the resource: a NULL keyword point= er has been provided.")); + VIR_INFO("Cannot update the resource: a NULL keyword pointer has b= een provided."); return false; } =20 if (readOnly) { if (!res->ro) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Cannot update the read-only keyword: RO sect= ion not initialized.")); + VIR_INFO("Cannot update the read-only keyword: RO section not = initialized."); return false; } =20 @@ -375,9 +371,7 @@ virPCIVPDResourceUpdateKeyword(virPCIVPDResource *res, = const bool readOnly, =20 } else { if (!res->rw) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _ - ("Cannot update the read-write keyword: read-wr= ite section not initialized.")); + VIR_INFO("Cannot update the read-write keyword: read-write sec= tion not initialized."); return false; } =20 @@ -476,8 +470,7 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, uin= t16_t resPos, uint16_t re if (virPCIVPDReadVPDBytes(vpdFileFd, buf, 3, fieldPos, csum) !=3D = 3) { /* Invalid field encountered which means the resource itself i= s invalid too. Report * That VPD has invalid format and bail. */ - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Could not read a resource field header - VPD= has invalid format")); + VIR_INFO("Could not read a resource field header - VPD has inv= alid format"); return false; } fieldDataLen =3D buf[2]; @@ -488,12 +481,10 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, u= int16_t resPos, uint16_t re =20 /* Handle special cases first */ if (!readOnly && fieldFormat =3D=3D VIR_PCI_VPD_RESOURCE_FIELD_VAL= UE_FORMAT_RESVD) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Unexpected RV keyword in the read-write sect= ion.")); + VIR_INFO("Unexpected RV keyword in the read-write section."); return false; } else if (readOnly && fieldFormat =3D=3D VIR_PCI_VPD_RESOURCE_FIE= LD_VALUE_FORMAT_RDWR) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Unexpected RW keyword in the read-only secti= on.")); + VIR_INFO("Unexpected RW keyword in the read-only section."); return false; } =20 @@ -517,21 +508,18 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, u= int16_t resPos, uint16_t re bytesToRead =3D fieldDataLen; break; default: - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Unexpected field value format encountere= d.")); + VIR_INFO("Unexpected field value format encountered."); return false; } =20 if (resPos + resDataLen < fieldPos + fieldDataLen) { /* In this case the field cannot simply be skipped since the p= osition of the * next field is determined based on the length of a previous = field. */ - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("A field data length violates the resource le= ngth boundary.")); + VIR_INFO("A field data length violates the resource length bou= ndary."); return false; } if (virPCIVPDReadVPDBytes(vpdFileFd, buf, bytesToRead, fieldPos, c= sum) !=3D bytesToRead) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Could not parse a resource field data - VPD = has invalid format")); + VIR_INFO("Could not parse a resource field data - VPD has inva= lid format"); return false; } /* Advance the position to the first byte of the next field. */ @@ -552,7 +540,7 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, uin= t16_t resPos, uint16_t re } else if (fieldFormat =3D=3D VIR_PCI_VPD_RESOURCE_FIELD_VALUE_FOR= MAT_RESVD) { if (*csum) { /* All bytes up to and including the checksum byte should = add up to 0. */ - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Checksum v= alidation has failed")); + VIR_INFO("Checksum validation has failed"); return false; } hasChecksum =3D true; @@ -578,8 +566,7 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd, uin= t16_t resPos, uint16_t re } /* The field format, keyword and value are determined. Attempt to = update the resource. */ if (!virPCIVPDResourceUpdateKeyword(res, readOnly, fieldKeyword, f= ieldValue)) { - virReportError(VIR_ERR_INTERNAL_ERROR, - _("Could not update the VPD resource keyword: %= s"), fieldKeyword); + VIR_INFO("Could not update the VPD resource keyword: %s", fiel= dKeyword); return false; } } @@ -627,14 +614,12 @@ virPCIVPDParseVPDLargeResourceString(int vpdFileFd, u= int16_t resPos, g_autofree char *buf =3D g_malloc0(resDataLen + 1); =20 if (virPCIVPDReadVPDBytes(vpdFileFd, (uint8_t *)buf, resDataLen, resPo= s, csum) !=3D resDataLen) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Could not read a part of a resource - VPD has in= valid format")); + VIR_INFO("Could not read a part of a resource - VPD has invalid fo= rmat"); return false; } resValue =3D g_strdup(g_strstrip(buf)); if (!virPCIVPDResourceIsValidTextValue(resValue)) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("The string resource has invalid characters in it= s value")); + VIR_INFO("The string resource has invalid characters in its value"= ); return false; } res->name =3D g_steal_pointer(&resValue); --=20 2.37.3