linux-kernel - Re: [PATCH RESEND 1/1] x86: tsc: avoid system instability in hibernation

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: <20180730085354.GA2494@hirez.programming.kicks-ass.net>
Date:   Mon, 30 Jul 2018 10:53:54 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Eduardo Valentin <eduval@...zon.com>
Cc:     "Rafael J . Wysocki" <rafael@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Dou Liyang <douly.fnst@...fujitsu.com>,
        Len Brown <len.brown@...el.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        "mike.travis@....com" <mike.travis@....com>,
        Rajvi Jingar <rajvi.jingar@...el.com>,
        Pavel Tatashin <pasha.tatashin@...cle.com>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        x86@...nel.org, linux-kernel@...r.kernel.org,
        linux-pm@...r.kernel.org
Subject: Re: [PATCH RESEND 1/1] x86: tsc: avoid system instability in
 hibernation

On Thu, Jul 26, 2018 at 08:56:56AM -0700, Eduardo Valentin wrote:
> System instability are seen during resume from hibernation when system
> is under heavy CPU load. This is due to the lack of update of sched
> clock data

Which would suggest you're already running with unstable sched clock.
Otherwise nobody would care about the scd stuff.

What kind of machine are you running? What does:

  dmesg | grep -i tsc

say?

> The fix for this situation is to mark the sched clock as unstable
> as early as possible in the resume path, leaving it unstable
> for the duration of the resume process. This will force the
> scheduler to attempt to align the sched clock across CPUs using
> the delta with time of day, updating sched clock data. In a post
> hibernation event, we can then mark the sched clock as stable
> again, avoiding unnecessary syncs with time of day on systems
> in which TSC is reliable.

None of this makes any sense. Either you were already unstable and it
should already have worked and them marking it stable is an outright
bug, or your sched clock was stable but then your initial diagnosis of
lack of scd updates is complete garbage.