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: <01000163f00c1dd6-11e49be4-fe96-49cf-bbf6-8d951874faa1-000000@email.amazonses.com>
Date:   Mon, 11 Jun 2018 18:11:56 +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 01:56 PM, Jeremy Cline wrote:
> 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 :(

Attached is the Fedora configuration for 4.16.8, as well, in case you'd
like to test it with that.

Thanks,
Jeremy

View attachment "config" of type "text/plain" (196376 bytes)