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: <CA+ToGPHtL0Fd3TgqakqmEtKi7z6jszpoEdJcO+EyD9yh8pGTyQ@mail.gmail.com>
Date:   Mon, 11 Jun 2018 16:23:50 -0300
From:   Diego Viola <diego.viola@...il.com>
To:     Jeremy Cline <jeremy@...ine.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        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,
        mmarget@...sik.tu-berlin.de
Subject: Re: Regression: x86/tsc: Fix mark_tsc_unstable()

On Mon, Jun 11, 2018 at 3:11 PM, Jeremy Cline <jeremy@...ine.org> wrote:
> 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

Hi Jeremy,

I've compiled 4.16.8 with your config and booted my machine about 10
times with this kernel, and I'm unable to reproduce the issue.

Maybe it's an issue with the Fedora initramfs?

Diego