linux-kernel - Re: Regression: x86/tsc: Fix mark_tsc

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]

Message-ID: <01000163effdcb29-f886b68d-bdb4-44c0-a68e-f749e10280fd-000000@email.amazonses.com>
Date:   Mon, 11 Jun 2018 17:56:17 +0000
From:   Jeremy Cline <jeremy@...ine.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        rui.zhang@...el.com, len.brown@...el.com, stable@...r.kernel.org,
        linux-kernel@...r.kernel.org, regressions@...mhuis.info,
        Diego Viola <diego.viola@...il.com>,
        mmarget@...sik.tu-berlin.de
Subject: Re: Regression: x86/tsc: Fix mark_tsc_unstable()

On 06/11/2018 11:30 AM, Peter Zijlstra wrote:
> On Mon, Jun 11, 2018 at 04:38:01PM +0200, Peter Zijlstra wrote:
>> On Mon, Jun 11, 2018 at 04:17:42PM +0200, Peter Zijlstra wrote:
>>> On Mon, Jun 11, 2018 at 01:59:15PM +0000, Jeremy Cline wrote:
>>>> A user has bisected the problem to the v4.16 commit 1ab4ca7c59d4
>>>> ("x86/tsc: Fix mark_tsc_unstable()"). According to the reporter,
>>>> explicitly setting "tsc=" on the kernel command line causes the boot to
>>>> always succeed. All the users have Thinkpad T500s or T400s (Core 2 Duos)
>>>
>>> Weird. So Core2 typically triggers mark_tsc_unstable() in either
>>> intel_idle or processor_idle. ISTR testing that when I did the patches.
>>>
>>> When I make that mark_tsc_unstable() in the idle drivers unconditional
>>> and boot my ivb with that, it doesn't want to fail. I've booted the
>>> machine 5 consequctive times without issue.
>>>
>>> Let me try and checkout -stable, maybe something's up with that.
>>
>> Nope -stable seems to be working as well on the IVB (with modification).
>> I just dug up my T500 and that's actually still running the test kernel.
>> Let me try and build the -stable kernel for that.
> 
> 4.16.8 works without issue on my T500 with a debian/ubuntu like distro
> config.
> 

Adding mmarget (who bisected the problem) to the CC.

It might well be something Fedora-specific, then. I just noticed mmarget
commented over the weekend noting that they couldn't reproduce the
problem without using the initramfs generated during the RPM install of
the kernel. mmarget's theory was that it's a race condition that doesn't
occur when the initramfs takes long enough to unpack, but I don't know
enough about the early boot process *or* how Fedora's generating the
initramfs for RPM installs vs "make install" yet to know how likely that
is. I'm going to have to do some research.

Thanks for looking into this so quickly and also sorry if this turns out
to be a Fedora problem :(

Thanks,
Jeremy