linux-kernel - Re: [PATCH] x86/ioapic: don't use unstable TSC to detect timer IRQ

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1803200956580.6506@nanos.tec.linutronix.de>
Date:   Tue, 20 Mar 2018 10:00:09 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Liu, Changcheng" <changcheng.liu@...el.com>
cc:     hpa@...or.com, peterz@...radead.org, douly.fnst@...fujitsu.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/ioapic: don't use unstable TSC to detect timer IRQ

On Tue, 20 Mar 2018, Liu, Changcheng wrote:

> In rare case, the TSC is every unstable or can't sync with
> real time hardware clock.

What does that mean?

> After setting "tsc=unstable" in command line, system should use
> delay_without_tsc to detect timer IRQ. Or system could panic as shown in
> below log:

tsc=unstable has nothing to do with TSC being usable for delay loops unless
your TSC is completely broken. Please explain more detailed in which way
this TSC is defect in the hardware. Aside of that is this production
hardware or some experimental silicon?

> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
> index fb43027..27b1bae 100644
> --- a/arch/x86/kernel/tsc.c
> +++ b/arch/x86/kernel/tsc.c
> @@ -36,7 +36,8 @@ EXPORT_SYMBOL(tsc_khz);
>  /*
>   * TSC can be unstable due to cpufreq or due to unsynced TSCs
>   */
> -static int __read_mostly tsc_unstable;
> +int __read_mostly tsc_unstable;
> +EXPORT_SYMBOL(tsc_unstable);

Even if we decided to do that, there is no need to export that symbol ever.

Thanks,

	tglx