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

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]

Message-ID: <87ldwd7urh.ffs@tglx>
Date: Wed, 18 Dec 2024 00:30:10 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Atharva Tiwari <evepolonium@...il.com>
Cc: evepolonium@...il.com, Ingo Molnar <mingo@...hat.com>, Borislav Petkov
 <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>,
 Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot
 <vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>,
 Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Mel
 Gorman <mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>, Peter
 Hilber <peter.hilber@...nsynergy.com>, Lakshmi Sowjanya D
 <lakshmi.sowjanya.d@...el.com>, Feng Tang <feng.tang@...el.com>, Marco
 Elver <elver@...gle.com>, "Paul E. McKenney" <paulmck@...nel.org>, Randy
 Dunlap <rdunlap@...radead.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/tsc: avoid system instability in hibernation System

On Mon, Dec 16 2024 at 16:06, Atharva Tiwari wrote:
> instability are seen during resume from hibernation when system is under heavy CPU load. this is caused by the lack of update of sched clock data

Neither the subject nor the change log text make any sense. (formatting ignored)

Aside of that you still have not answered the question from Peter:

  https://lore.kernel.org/all/20241210123516.GP8562@noisy.programming.kicks-ass.net

and you keep resending the same patch over and over without any
explanation about the underlying problem.

Actually after Peter asked you to provide details, you reduced the
information in the changelog and resent the thing twice within a few
hours. The second time with a even more broken changelog. Then five days
later you repeat the exercise with a resend of the second variant.

May I ask you to read Documentation/process/* to figure out how this
works?

You can resend this as much as you want, as long as you don't provide
answers to the questions asked, this is going nowhere.

Let me ask you more detailed questions:

> +static int tsc_pm_notifier(struct notifier_block *notifier,
> +                          unsigned long pm_event, void *unused)
> +{
> +	switch (pm_event) {
> +	case PM_HIBERNATION_PREPARE:
> +		clear_sched_clock_stable();

This marks a stable sched clock unstable, which means that the simple
fast path of reading the clock:

      sched_clock_noinstr() + __sched_clock_offset;

is disabled and the system has to update the sched clock data for no
good reason.

Questions:

   1) What has this to do with heavy CPU load?

   2) What has this to do with the system not updating sched clock data,
      especially as a stable sched clock does not require any sched clock
      data updates at all?

   3) Can you provide dmesg output or any other evidence which backs up
      your reasoning to mark sched clock unstable when preparing for
      hibernation?

Thanks,

        tglx