linux-kernel - Re: [PATCH] i386: add command line option "local_apic_timer_c2

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, 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/