linux-kernel - pm: System date and time set incorrectly after suspend/resume to disk

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

Date:	Tue, 18 Jun 2013 01:30:57 +0000
From:	Shuah Khan <shuah.kh@...sung.com>
To:	"rjw@...k.pl" <rjw@...k.pl>,
	"a.zummo@...ertech.it" <a.zummo@...ertech.it>
Cc:	"rtc-linux@...glegroups.com" <rtc-linux@...glegroups.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Shuah Khan <shuah.kh@...sung.com>,
	"shuahkhan@...il.com" <shuahkhan@...il.com>
Subject: pm: System date and time set incorrectly after suspend/resume to disk

I am seeing a problem on my system after a suspend to disk in reboot or 
shutdown mode. When pm_trace is 0 (which is the default), I can't 
reproduce the problem easily. I have to run a few more suspend tests 
before I see the problem. When pm_trace is disabled, the problem showed 
up when I ran suspend in platform mode in a row. However when pm_ptrace 
is enabled, problem happens on the very first spend to disk in reboot mode.

Steps to run into the issue:

echo 1 > pm_print_times
echo 1 > pm_trace
echo reboot > disk
echo disk > state

or

echo 1 > pm_print_times
echo 1 > pm_trace
echo shutdown > disk
echo disk > state

When system comes back up, system time set to incorrect time.

In this latest round of testing:

time before suspend was Mon Jun 17 16:27 MDT 2013
right after resume was Thu Oct 5 18:24:42 MDT 2028

I have NTP enabled on my system and I have to disable/re-enable NTP from 
Time and Date config menu.

rtc class suspend routine rtc_suspend() does adjustments to account for 
the time spent suspended. Is that the right one run in this case?

rtc_suspend() doesn't run because has_persistent_clock() returns true. 
rtc-cmos pnp driver suspend routines runs.

It is a possible race condition that is triggered when the conditions 
are right.

I have the following enabled in my config

CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"

Looking for tips on debugging the problem.

thanks,
-- Shuah
Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research 
America (Silicon Valley) shuah.kh@...sung.com | (970) 672-0658

--
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/