linux-kernel - Re: TSC not updating after resume: Bug or Feature?

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: <1230281241.9487.266.camel@twins>
Date:	Fri, 26 Dec 2008 09:47:21 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Pavel Machek <pavel@...e.cz>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Fabio Comolli <fabio.comolli@...il.com>,
	Ingo Molnar <mingo@...e.hu>, "Rafael J. Wysocki" <rjw@...k.pl>,
	Steven Rostedt <srostedt@...hat.com>, dsaxena@...xity.net,
	LKML <linux-kernel@...r.kernel.org>,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>,
	toralf.foerster@....de
Subject: Re: TSC not updating after resume: Bug or Feature?

On Wed, 2008-12-24 at 15:09 +0100, Pavel Machek wrote:
> Hi!
> > > >
> > > > Can please you revert the last patch and apply the following ? Does
> > > > the WARN_ON trigger ?
> > > >
> > 
> > > Yes, it does:
> >  
> > > [  159.768005]  [<c01389a2>] getnstimeofday+0x21/0xcd
> > > [  159.768005]  [<c0135e26>] ktime_get_ts+0x1d/0x3f
> > > [  159.768005]  [<c0135e57>] ktime_get+0xf/0x2b
> > > [  159.768005]  [<c013736b>] sched_clock_tick+0x46/0x83
> > > [  159.768005]  [<c01373ad>] sched_clock_idle_wakeup_event+0x5/0xa
> > > [  159.768005]  [<c0108670>] set_cyc2ns_scale+0x3f/0x5e
> > > [  159.768005]  [<c01088af>] time_cpufreq_notifier+0xf9/0x103
> > > [  159.768005]  [<c0136782>] notifier_call_chain+0x2a/0x52
> > > [  159.768005]  [<c0136866>] __srcu_notifier_call_chain+0x35/0x4a
> > > [  159.768005]  [<c0136884>] srcu_notifier_call_chain+0x9/0xc
> > > [  159.768005]  [<c031cbca>] cpufreq_resume+0xf3/0x112
> > > [  159.768005]  [<c028c3f3>] __sysdev_resume+0x24/0x34
> > > [  159.768005]  [<c028c421>] sysdev_resume+0x1e/0x50
> > 
> > Thanks for testing. It's exaclty the code path I described :)
> > 
> > So my code analysis holds and your test confirms my suspicion that
> > Shaggy's patch just unearthed some other weirdness in the
> > suspend/resume code.
> > 
> > Can you please apply the following hack^Wpatch and retest ? It
> > restores Shaggys patch, but prevents the sched_clock_tick() call when
> > timekeeping is not resumed. The WARN_ON should not longer trigger
> > except there is some other code path which fiddles with that as well.
> > 
> > If I'm not completely nuts then this should solve your suspend/resume
> > problem really instead of papering over the root cause.
> 
> Should we move timekeeping resume before cpufreq resume, instead of this?

That seems a sensible suggestion (but I've got no clue on how practical
that is). A quick look at the boot code suggests that regular bootups
have that sequence as well, so mirroring that in the resume code seems
like the best all-round solution.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/