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]
Date:	Thu, 16 May 2013 13:55:57 -0400
From:	Josh Boyer <jwboyer@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	x86@...nel.org, linux-kernel@...r.kernel.org, gleb@...hat.com,
	Robert Richter <rric@...nel.org>
Subject: Re: Drop WARN on AMD lack of perfctrs

On Thu, May 16, 2013 at 07:51:17PM +0200, Peter Zijlstra wrote:
> On Thu, May 16, 2013 at 11:10:26AM -0400, Josh Boyer wrote:
> > Hi All,
> > 
> > If you boot a KVM guest on an AMD family 15h and specify -cpu host,
> > you'll get the following splat:
> > 
> > [    0.031000] ------------[ cut here ]------------
> > [    0.031000] WARNING: at arch/x86/kernel/cpu/perf_event_amd.c:772
> > amd_pmu_init+0x18c/0x249()
> > [    0.031000] Hardware name: Bochs
> > [    0.031000] Odd, counter constraints enabled but no core perfctrs
> > detected!
> > [    0.031000] Modules linked in:
> > 
> > [    0.031000] Pid: 1, comm: swapper/0 Not tainted
> > 3.9.0-0.rc1.git0.4.fc19.x86_64 #1
> > [    0.031000] Call Trace:
> > [    0.031000]  [<ffffffff81d10c67>] ? amd_pmu_init+0x18c/0x249
> > [    0.031000]  [<ffffffff8105c9a0>] warn_slowpath_common+0x70/0xa0
> > [    0.031000]  [<ffffffff81d106b3>] ? check_bugs+0x2d/0x2d
> > [    0.031000]  [<ffffffff8105ca1c>] warn_slowpath_fmt+0x4c/0x50
> > [    0.031000]  [<ffffffff81d10c67>] amd_pmu_init+0x18c/0x249
> > [    0.031000]  [<ffffffff81d106e7>] init_hw_perf_events+0x34/0x428
> > [    0.031000]  [<ffffffff81d106b3>] ? check_bugs+0x2d/0x2d
> > [    0.031000]  [<ffffffff8100210a>] do_one_initcall+0x10a/0x160
> > [    0.031000]  [<ffffffff81d06fa5>] kernel_init_freeable+0xcf/0x1fa
> > [    0.031000]  [<ffffffff81629800>] ? rest_init+0x80/0x80
> > [    0.031000]  [<ffffffff8162980e>] kernel_init+0xe/0x190
> > [    0.031000]  [<ffffffff8164e22c>] ret_from_fork+0x7c/0xb0
> > [    0.031000]  [<ffffffff81629800>] ? rest_init+0x80/0x80
> > [    0.031000] ---[ end trace a1e57d3cb8668105 ]---
> > 
> > That seems a bit excessive, and it gets picked up by auto-reporting
> > tools like ABRT as a bug.  Can we remove the WARN and just use pr_err or
> > something else instead?
> 
> Robert put that in, I suppose its because the CPUID crap indicates its got perf
> counters but then it doesn't actually have them.
> 
> Clearly this is something that should be fixed in your virt thingy instead.

Maybe.  But do you really need to dump a stack trace here?  What is a
user supposed to do with that information?  Can they fix the kernel?
Can the fix the CPU?  As far as I can tell, they can't do either.

Is using pr_err with the same message really somehow worse than using
WARN?

josh
--
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