From nobody Thu Sep 19 01:21:46 2024 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=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 1721311785858952.7526886933414; Thu, 18 Jul 2024 07:09:45 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 996) id CA84AA24; Thu, 18 Jul 2024 10:09:44 -0400 (EDT) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id BAFD9C94; Thu, 18 Jul 2024 10:08:27 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 996) id B8E42C64; Thu, 18 Jul 2024 10:08:23 -0400 (EDT) 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 07CD5A00 for ; Thu, 18 Jul 2024 10:08:17 -0400 (EDT) Received: from mx-prod-mc-05.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-635-nwF8nhejMxG-Mzhe_B4hIw-1; Thu, 18 Jul 2024 10:08:16 -0400 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 489C51954205 for ; Thu, 18 Jul 2024 14:08:15 +0000 (UTC) Received: from maggie.brq.redhat.com (unknown [10.43.3.102]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 8CD5D1955E89 for ; Thu, 18 Jul 2024 14:08:14 +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=2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RCVD_IN_SBL_CSS,SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721311697; 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=RFCiJ3e4mjojE9oy8SqTFN0IxcnLjXkucnrt5aYBDto=; b=JtrOYY8EbFm4koX+yXRAZc8JMSt5MYI/G29v/NxkT4pYI8wCFlAhorz+mENJA9UzcqvhoK QWSyiYwg9EJdq4sRXKLORuzoZ2MhaHEau5C87M8cN1uF36XfYC8Mr2251Sdi/eQzodynIE YITR1apV1YKjunBgdI5/blJ/xfgzYug= X-MC-Unique: nwF8nhejMxG-Mzhe_B4hIw-1 From: Michal Privoznik To: devel@lists.libvirt.org Subject: [PATCH 4/5] virsysinfo: Be more forgiving when decoding OEM strings Date: Thu, 18 Jul 2024 16:08:06 +0200 Message-ID: <83608742292a2d914061e58ef3d0b88e9332bc10.1721311651.git.mprivozn@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Message-ID-Hash: WZEQGK4JNLLEVM6IQY26VEGBM7YRJ52Q X-Message-ID-Hash: WZEQGK4JNLLEVM6IQY26VEGBM7YRJ52Q X-MailFrom: mprivozn@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: X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1721311786136116600 Content-Type: text/plain; charset="utf-8"; x-default="true" On some systems, there are two or even more 'OEM Strings' sections in DMI table. Here's an example of dmidecode output on such system: # dmidecode -q -t 11 OEM Strings String 1: Default string OEM Strings String 1: ThunderX2 System String 2: cavium.com String 3: Comanche Now, this poses a problem, because when one tries to obtain individual strings, they get: # dmidecode -q --oem-string 1 Default string ThunderX2 System # dmidecode -q --oem-string 2 No OEM string number 2 cavium.com NB, the "No OEM string number 2" is printed onto stderr and everything else onto stdout. Oh, and trying to get OEM strings from just one section doesn't fly: # dmidecode -q -H 0x1d --oem-string 2 Options --string, --type, --handle and --dump-bin are mutually exclusive This means two things: 1) we have no way of distinguishing OEM strings at the same index but in different sections, 2) because of how virSysinfoDMIDecodeOEMString() is written, we fail in querying OEM string that exists in one section but not in the others (for instance string #2 from example above). While there's not much we can do about 1), there is something that can be done about 2) - refine the error condition and make the function return an error iff there's nothing on stdout and there's something on stderr. Resolves: https://issues.redhat.com/browse/RHEL-45952 Signed-off-by: Michal Privoznik --- src/util/virsysinfo.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c index cdc2a7d87b..1fd8261dc1 100644 --- a/src/util/virsysinfo.c +++ b/src/util/virsysinfo.c @@ -910,9 +910,20 @@ virSysinfoDMIDecodeOEMString(size_t i, =20 /* Unfortunately, dmidecode returns 0 even if OEM String index is out * of bounds, but it prints an error message in that case. Check stderr - * and return success/failure accordingly. */ + * and return success/failure accordingly. + * To make matters worse, if there are two or more 'OEM String' + * sections then: + * + * a) we have no way of distinguishing them as dmidecode prints + * strings from all sections, + * b) if one section contains a valid string, but the other doesn't, + * then stdout contains the valid string and stderr contains the + * error "No OEM string number X*. + * + * Let's just hope there is not many systems like that. + */ =20 - if (err && *err !=3D '\0') + if (!(*str && **str !=3D '\0') && err && *err !=3D '\0') return -1; =20 virStringTrimOptionalNewline(*str); --=20 2.44.2