From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756014AbbESR0k (ORCPT ); Tue, 19 May 2015 13:26:40 -0400 Received: from mail-oi0-f48.google.com ([209.85.218.48]:35907 "EHLO mail-oi0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755558AbbESR0A (ORCPT ); Tue, 19 May 2015 13:26:00 -0400 MIME-Version: 1.0 In-Reply-To: <1432050210-32036-1-git-send-email-prarit@redhat.com> References: <1432050210-32036-1-git-send-email-prarit@redhat.com> Date: Tue, 19 May 2015 13:25:59 -0400 Message-ID: Subject: Re: [PATCH] x86, cpuinfo x86_model_id whitespace cleanup From: Brian Gerst To: Prarit Bhargava Cc: Linux Kernel Mailing List , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "the arch/x86 maintainers" , Andy Lutomirski , Borislav Petkov , Denys Vlasenko , Dave Hansen , Igor Mammedov , Fenghua Yu Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 19, 2015 at 11:43 AM, Prarit Bhargava wrote: > When comparing 'model name' fields in /proc/cpuinfo it was noticed that > a simple test comparing the model name fields was failing. After some > quick investigation it was noticed that the model name fields were actually > different -- processor 0's model name field had trailing white space removed, > while the other processors did not. > > Another way of seeing this behaviour is to convert spaces into underscores > in the output of /proc/cpuinfo, > > [thetango@prarit ~]# grep "^model name" /proc/cpuinfo | uniq -c | sed 's/\ /_/g' > ______1_model_name :_AMD_Opteron(TM)_Processor_6272 > _____63_model_name :_AMD_Opteron(TM)_Processor_6272_________________ > > which shows two different model name fields even though they should be the > same. > > This occurs because the kernel calls strim() on cpu 0's x86_model_id field > to output a pretty message to the console in print_cpu_info(), and as a > result truncates the whitespace at the end of the x86_model_id field. > > The x86_model_id field should be the same for the same processors. This > patch uses string functions to remove both leading and trailing whitespace > in the x86_model_id field. As a result the print_cpu_info() output looks > like > > smpboot: CPU0: AMD Opteron(TM) Processor 6272 (fam: 15, model: 01, stepping: 02) > > and the x86_model_id field is correct on all processors on AMD platforms > > [thetango@prarit ~]# grep "^model name" /proc/cpuinfo | uniq -c | sed 's/\ /_/g' > _____64_model_name :_AMD_Opteron(TM)_Processor_6272 > > and the functionality is correct on an Intel box: > > [thetango@prarit2]# grep "^model name" /proc/cpuinfo | uniq -c | sed 's/\ /_/g' > ____144_model_name :_Intel(R)_Xeon(R)_CPU_E7-8890_v3_@_2.50GHz > > Signed-off-by: Prarit Bhargava > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: x86@kernel.org > Cc: Andy Lutomirski > Cc: Borislav Petkov > Cc: Denys Vlasenko > Cc: Dave Hansen > Cc: Igor Mammedov > Cc: Fenghua Yu > Cc: Brian Gerst > --- > arch/x86/kernel/cpu/common.c | 17 ++++------------- > 1 file changed, 4 insertions(+), 13 deletions(-) > > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index a62cf04..9405c1e 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -419,7 +419,6 @@ static const struct cpu_dev *cpu_devs[X86_VENDOR_NUM] = {}; > static void get_model_name(struct cpuinfo_x86 *c) > { > unsigned int *v; > - char *p, *q; > > if (c->extended_cpuid_level < 0x80000004) > return; > @@ -431,18 +430,10 @@ static void get_model_name(struct cpuinfo_x86 *c) > c->x86_model_id[48] = 0; > > /* > - * Intel chips right-justify this string for some dumb reason; > - * undo that brain damage: > + * Remove leading whitespace on Intel processors and trailing > + * whitespace on AMD processors. > */ > - p = q = &c->x86_model_id[0]; > - while (*p == ' ') > - p++; > - if (p != q) { > - while (*p) > - *q++ = *p++; > - while (q <= &c->x86_model_id[48]) > - *q++ = '\0'; /* Zero-pad the rest */ > - } > + strlcpy(c->x86_model_id, strim(c->x86_model_id), 48); > } Using strlcpy in this manner could fail if it does larger than byte copies and they overlap. I would instead allocate a temp buffer on the stack: unsigned char model_id[49]; v = (unsigned int *)model_id; ... strlcpy(c->x86_model_id, strim(model_id), 48); -- Brian Gerst