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

On Thu, May 16, 2013 at 10:55:58PM +0200, Robert Richter wrote:
> On 16.05.13 20:10:18, Peter Zijlstra wrote:
> > On Thu, May 16, 2013 at 01:55:57PM -0400, Josh Boyer wrote:
> > > 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.
> > 
> > Send their CPU back to AMD is I suppose the best they can do ;-)
> >  
> > > Is using pr_err with the same message really somehow worse than using
> > > WARN?
> > 
> > I would make it a FW_BUG as well. But yeah, I suppose that is a better option
> > than the WARN_ON. Unless Robert had a different reason...
> 
> iirc the reason was the different msr range that is switched on fam15h
> with a different counter to counter msr offset of 2 instead of 1. The
> code relies on the assumption that the msrs exist on that cpu. Thus
> the warning if not. Also note that code may have changed in 3.10 in
> that area.

Again, what is someone supposed to do with a backtrace from the WARN?
As far as I can see, a user can't really do anything other than report
it and then there's nothing to fix.

The code might have moved in 3.10, but the WARN is still there.

Would you like me to send a patch to get it reduced to pr_err?

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