On Mon, May 18, 2015 at 3:45 PM, Borislav Petkov <[email protected]> wrote: > On Mon, May 18, 2015 at 02:21:00PM -0400, 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 >> simple investigation it was noticed that, in fact, the model name fields >> are different for each processor. Processor 0's model name field had >> 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 > > I'd actually prefer this much simpler patch: > > --- > diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c > index e7d8c7608471..d215e9b26567 100644 > --- a/arch/x86/kernel/cpu/proc.c > +++ b/arch/x86/kernel/cpu/proc.c > @@ -67,7 +67,7 @@ static int show_cpuinfo(struct seq_file *m, void *v) > c->x86_vendor_id[0] ? c->x86_vendor_id : "unknown", > c->x86, > c->x86_model, > - c->x86_model_id[0] ? c->x86_model_id : "unknown"); > + c->x86_model_id[0] ? strim(c->x86_model_id) : "unknown"); > > if (c->x86_mask || c->cpuid_level >= 0) > seq_printf(m, "stepping\t: %d\n", c->x86_mask);
The problem here is that strim() modifies the string in place, replacing the first trailing space with a null. I think the best solution is to do the trimming in get_model_name(). It already trims leading spaces for Intel. -- Brian Gerst -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
