From: "H. Peter Anvin" <hpa@zytor.com>
To: akataria@vmware.com
Cc: Andi Kleen <andi@firstfloor.org>, Ingo Molnar <mingo@elte.hu>,
LKML <linux-kernel@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
Daniel Hecht <dhecht@vmware.com>
Subject: Re: [PATCH 1/4] Check for serial key in dmi_name_in_vendors
Date: Fri, 31 Oct 2008 15:50:26 -0700 [thread overview]
Message-ID: <490B8BB2.3070105@zytor.com> (raw)
In-Reply-To: <1224894097.28224.71.camel@alok-dev1>
Alok Kataria wrote:
> Add serial key as a field to check for in dmi_name_in_vendors.
>
> From: Alok N Kataria <akataria@vmware.com>
>
> In some user configured cases, VMware may choose not to put a VMware specific
> DMI string, but the serial key is always there and is VMware specific.
> Add that too to check for in the dmi_name_in_vendors function.
>
> Signed-off-by: Alok N Kataria <akataria@vmware.com>
> ---
>
> drivers/firmware/dmi_scan.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
>
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index 3e526b6..14fcb52 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -476,7 +476,8 @@ int dmi_name_in_vendors(const char *str)
> {
> static int fields[] = { DMI_BIOS_VENDOR, DMI_BIOS_VERSION, DMI_SYS_VENDOR,
> DMI_PRODUCT_NAME, DMI_PRODUCT_VERSION, DMI_BOARD_VENDOR,
> - DMI_BOARD_NAME, DMI_BOARD_VERSION, DMI_NONE };
> + DMI_BOARD_NAME, DMI_BOARD_VERSION, DMI_PRODUCT_SERIAL,
> + DMI_NONE };
> int i;
> for (i = 0; fields[i] != DMI_NONE; i++) {
> int f = fields[i];
>
On reviewing this, I'm quite nervous about this patch.
dmi_name_in_vendors() is matched against short strings like "IBM" which
could end up in the serial number of another product by pure chance if
some vendor uses alpha serial numbers.
In fact, the *only* instance of dmi_name_in_vendors() in the upstream
kernel tree that "git grep" can find is:
drivers/misc/thinkpad_acpi.c: if (dmi_name_in_vendors("IBM"))
drivers/misc/thinkpad_acpi.c: else if (dmi_name_in_vendors("LENOVO"))
I think matching against the serial number would be just plain wrong here.
Since there is only one user, we could change that user, perhaps to take
a bitmask or pointer to one of several canned lists as an argument, or
we can introduce another entry point.
-hpa
next prev parent reply other threads:[~2008-10-31 22:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-25 0:21 [PATCH 1/4] Check for serial key in dmi_name_in_vendors Alok Kataria
2008-10-31 22:50 ` H. Peter Anvin [this message]
2008-11-01 2:01 ` Alok Kataria
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=490B8BB2.3070105@zytor.com \
--to=hpa@zytor.com \
--cc=akataria@vmware.com \
--cc=andi@firstfloor.org \
--cc=dhecht@vmware.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.