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:   Wed, 07 Jul 2021 12:04:11 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "zhaoyan.liao" <zhaoyan.liao@...ux.alibaba.com>, mingo@...hat.com,
        hpa@...or.com, dwmw@...zon.co.uk
Cc:     linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
        songmuchun@...edance.com, likunkun@...edance.com,
        guancheng.rjk@...baba-inc.com,
        "zhaoyan.liao" <zhaoyan.liao@...ux.alibaba.com>
Subject: Re: [PATCH] use 64bit timer for hpet

Liao,

On Fri, Jul 02 2021 at 16:13, zhaoyan liao wrote:
> The kernel judges whether the tsc clock is accurate in the
> clocksource_watchdog background thread function. The hpet clock source
> is 32-bit, but tsc is 64-bit. Therefore, when the system is busy and the
> clocksource_watchdog cannot be scheduled in time, the hpet clock may
> overflow and cause the system to misjudge tsc as unreliable.

Seriously? The wrap-around time for 32bit HPET @24MHz is ~3 minutes.

> In this case, we recommend that the kernel adopts the 64-bit hpet clock
> by default to keep the width of the two clock sources the same to reduce
> misjudgment. Some CPU models may not support 64-bit hpet, but according
> to the description of the CPU's register manual, it does not affect our
> reading action.

So much for the theory.

> -#define HPET_MASK			CLOCKSOURCE_MASK(32)
> +#define HPET_MASK			CLOCKSOURCE_MASK(64)

How is that valid for a 32bit HPET? This breaks the clocksource.
 
> +inline unsigned long hpet_readq(unsigned int a)
> +{
> +	return readq(hpet_virt_address + a);

Breaks 32bit build immediately.

Aside of that the reason why the kernel does not support 64bit HPET is
that there are HPETs which advertise 64bit support, but the
implementation is buggy.

IOW, while this works for your hardware this breaks quite some parts of
the universe. Not really a good approach.

Thanks,

        tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ