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] [day] [month] [year] [list]

Date:   Mon, 11 Jun 2018 21:31:18 +0000
From:   Jeremy Cline <jeremy@...ine.org>
To:     Diego Viola <diego.viola@...il.com>
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 06/11/2018 03:23 PM, Diego Viola wrote:
> 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.

Thanks for confirming.

> 
> Maybe it's an issue with the Fedora initramfs?

Indeed, I'll dig into what exactly is different about the RPM-created
initramfs and the one created with "make install" to see if we can
narrow this down some more.

Thanks,
Jeremy