lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AE5E804.9060409@sgi.com>
Date:	Mon, 26 Oct 2009 11:18:44 -0700
From:	Mike Travis <travis@....com>
To:	Dmitry Adamushko <dmitry.adamushko@...il.com>
CC:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jack Steiner <steiner@....com>,
	Tigran Aivazian <tigran@...azian.fsnet.co.uk>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Andreas Mohr <andi@...as.de>, Hugh Dickins <hugh@...itas.com>,
	Hannes Eder <hannes@...neseder.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/8] SGI x86_64 UV: Limit the number of microcode messages



Dmitry Adamushko wrote:
> 2009/10/24 Mike Travis <travis@....com>:
>> Limit number of microcode messages of the form:
>>
>> [   50.887135] microcode: CPU0 sig=0x206e5, pf=0x4, revision=0xffff001
>>
>> [ ... ]
>>
>> --- linux.orig/arch/x86/kernel/microcode_intel.c
>> +++ linux/arch/x86/kernel/microcode_intel.c
>> @@ -165,7 +165,9 @@
>>        /* get the current revision from MSR 0x8B */
>>        rdmsr(MSR_IA32_UCODE_REV, val[0], csig->rev);
>>
>> -       printk(KERN_INFO "microcode: CPU%d sig=0x%x, pf=0x%x, revision=0x%x\n",
>> +       if (cpu_num < 4 || !limit_console_output(false))
>> +               printk(KERN_INFO
>> +                       "microcode: CPU%d sig=0x%x, pf=0x%x, revision=0x%x\n",
>>                        cpu_num, csig->sig, csig->pf, csig->rev);
>>
> 
> Hmm, I guess we wouldn't lose a lot by simply removing those messages
> completely. Per-cpu pf/revision is available via /sys anyway.
> 
> Alternatively, we might move the output into
> microcode_core.c::collect_cpu_info() (or even microcode_init_cpu()) so
> that the same logic is also applied for amd and do something as
> following:
> 
> don't print if a cpu info is equal to the info of CPU#0. I guess, any
> non-0 cpu would be even better as the microcode for cpu#0 can be
> loaded by BIOS, if I'm not mistaken. But then we can only be sure
> about the presence of cpu#0.
> 
> Anyway, it's not worthy of any additional complexity so I'd say let's
> just remove the output :-)
> 
> 
> -- Dmitry

I would be more than happy to remove messages but I didn't want to override
the original author's intent on why they choose to add these messages in the
first place.

Plus if you have a 64 or 128 cpu system, it might give you pleasure in seeing
all those cpu messages.  ;-)  Just when it hits around 256 and up that it
really starts getting annoying.

Thanks,
Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ