linux-kernel - RFD: Should we remove the HLT check? (was Re: [PATCH 1/8] x86: avoid check hlt if no timer interrupts)

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:	Fri, 07 May 2010 13:32:01 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jacob Pan <jacob.jun.pan@...ux.intel.com>
CC:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	Alek Du <alek.du@...el.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Feng Tang <feng.tang@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jacob Pan <jacob.jun.pan@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arjan van de Ven <arjan.van.de.ven@...el.com>
Subject: RFD: Should we remove the HLT check?  (was Re: [PATCH 1/8] x86: avoid
 check hlt if no timer interrupts)

On 05/07/2010 10:41 AM, Jacob Pan wrote:
> From: Jacob Pan <jacob.jun.pan@...el.com>
> 
> check hlt requires external timer interrupt to wake up the
> cpu. for platforms equipped with only per cpu timers, we don't
> have external interrupts during check hlt.
> this patch checks such condition to avoid kernel hang at hlt.
> it also saves boot time in that hlt four times in the current code
> requires four ticks to break out of them.
> 
> Signed-off-by: Jacob Pan <jacob.jun.pan@...el.com>
> Signed-off-by: Jacob Pan <jacob.jun.pan@...ux.intel.com>
> ---
>  arch/x86/include/asm/bugs.h |    1 +
>  arch/x86/kernel/cpu/bugs.c  |    4 ++++
>  2 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/include/asm/bugs.h b/arch/x86/include/asm/bugs.h
> index 08abf63..1e0cef8 100644
> --- a/arch/x86/include/asm/bugs.h
> +++ b/arch/x86/include/asm/bugs.h
> @@ -2,6 +2,7 @@
>  #define _ASM_X86_BUGS_H
>  
>  extern void check_bugs(void);
> +extern struct clock_event_device *global_clock_event;
>  
>  #if defined(CONFIG_CPU_SUP_INTEL) && defined(CONFIG_X86_32)
>  int ppro_with_ram_bug(void);
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 01a2652..c0d9688 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -90,6 +90,10 @@ static void __init check_hlt(void)
>  		return;
>  
>  	printk(KERN_INFO "Checking 'hlt' instruction... ");
> +	if (!global_clock_event) {
> +		printk(KERN_CONT "no clockevent to wake up, skipped.\n");
> +		return;
> +	}
>  	if (!boot_cpu_data.hlt_works_ok) {
>  		printk("disabled\n");
>  		return;

I really wish I knew the exact systems affected by the HLT bug.  If I
remember correctly, it was some 386 systems -- or possibly 486 systems
as well -- a very long time ago.  This test just provides a diagnosis if
the system really is bad (it hangs with an obvious message) at the cost
of some 40 ms to the system boot time.  I suspect C1 (HLT) being broken
is not anywhere close to the predominant power management problem in the
current day, and as such I'm wondering if this particular test hasn't
outlived its usefulness.

Thoughts?

	-hpa

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