linux-kernel - Re: TSC x86 fixes for LTS kernel 4.9.x

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, 13 Dec 2017 12:14:14 +0200
From:   Dan Aloni <dan@...nelim.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     stable@...r.kernel.org,
        Linux Kernel List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Bin Gao <bin.gao@...ux.intel.com>
Subject: Re: TSC x86 fixes for LTS kernel 4.9.x

On Wed, Dec 13, 2017 at 10:57:55AM +0100, Greg KH wrote:
> On Wed, Dec 13, 2017 at 11:45:20AM +0200, Dan Aloni wrote:
> > git cherry-pick -x 16588f659257 # x86/tsc: Annotate printouts as firmware bug
> > git cherry-pick -x 8c9b9d87b855 # x86/tsc: Limit the adjust value further
> > 
> > There's a conflict only in a one small place in the first few patches.
>[..]
> That's a lot of changes to be backported.  I'm _really_ hesitant to do
> this, unless the maintainer of the code agrees it is ok...

I guessed so, that's why I probed. Otherwise I would have just sent
out patches.

> > > > These changes percisely fix an issue I am having with a relatively new
> > > > 8-core Intel(R) Core(TM) i7-7820X with an updated ASUS BIOS (December 2017).
> > > > 
> > > > Under v4.9.68, the kernel fallbacks on the chosen clocksource to HPET which
> > > > just doesn't work - there is over a 200ms time drift that does not go
> > > > away even after repeated ntpdate sync attempts.
> > > > 
> > > > For further testing I've posted a branch for these changes here:
> > > > 
> > > >     https://github.com/kernelim/linux tsc-fix-for-4.9.x
> > > 
> > > Why not just use 4.14 instead?  That's much easier than trying to use an
> > > old kernel like 4.9, right?
> > 
> > Yes, however the milage of 4.9.x seems more appealing somewhat.
> 
> Why?  4.14 should be much better, it's newer, has more hardware support,
> more bugs fixed, and more new things left to debug :)

I always enjoy debugging :)

> > I'll give 4.14.x a try mostly to see whether it solves hard locks that
> > I've seen with 4.13.x (all Fedora-based stable kernels) on three of my
> > machines -- an unrelated issue, and the main reason why I gave one of
> > the LTS branches a try.
>
> You really should report that.  Without that, odds are it will not be
> fixed.

I am still collecting data, but these systems are being used rather
constantly so the downtime is problematic. It's a) a rather new
workstation, 2) an Intel Nuc, and 3) An old Lenovo Carbon X1 Gen 3.

I should have also used a vanilla build because I know that on LKML
it has preference over the Fedora-based patchset. I will try to see
if it produces on 4.14.x and perhaps kdump will be able to capture
it this time.

-- 
Dan Aloni