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: <20070329214520.GA3185@rhlx01.hs-esslingen.de>
Date:	Thu, 29 Mar 2007 23:45:21 +0200
From:	Andreas Mohr <andi@...x01.fht-esslingen.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andi Kleen <ak@...e.de>, Mark Langsdorf <mark.langsdorf@....com>,
	Len Brown <lenb@...nel.org>,
	"Morrow, William" <William.Morrow@....com>,
	"Crouse, Jordan" <jordan.crouse@...mail.amd.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Pavel Machek <pavel@....cz>, Ingo Molnar <mingo@...e.hu>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Mingming Cao <cmm@...ibm.com>, Adrian Bunk <bunk@...sta.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	Mariusz Kozlowski <m.kozlowski@...land.pl>,
	Oliver Pinter <oliver.pntr@...il.com>,
	Sid Boyce <g3vbv@...eyonder.co.uk>,
	Nick Piggin <npiggin@...e.de>,
	Jens Axboe <jens.axboe@...cle.com>,
	Thomas Renninger <trenn@...e.de>
Subject: Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

Hi,

On Thu, Mar 29, 2007 at 02:16:54PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 29 Mar 2007, Andi Kleen wrote:
> > 
> > Here's a patch. I don't have a system with C1E, so i only tested that
> > the apic timer still works on a older AMD box.
> 
> I think this looks better than what we have now, but it would look even 
> better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we 
> simply had X86_FEATURE_BROKEN_C1_LAPIC etc..

Please don't, this would break the interface logically.
X86_FEATURE_xxx usually denotes a *feature*, not a "feature"
(Micro$oft speak for "bug" ;).
IOW most flags express a positive attribute, not a negative one.
An exception to this probably is X86_FEATURE_FXSAVE_LEAK and
X86_FEATURE_CMP_LEGACY, but all others seem to be positive, so we might
want to enforce this rule.

Thus, how about e.g. X86_FEATURE_LAPIC_C1_OK?
Or is this less precise from a "C1 working ok" detection point of view?
(i.e. we'd just assume by default that most machines are ok except the ones
where we have issue detection code for, which might be too fuzzy)

Andreas Mohr
-
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