linux-kernel - [PATCH] mn10300: time: Provide 64-bit persistent clock time

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1437439549-1012-1-git-send-email-xlpang@126.com>
Date:	Tue, 21 Jul 2015 08:45:49 +0800
From:	Xunlei Pang <xlpang@....com>
To:	linux-kernel@...r.kernel.org
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	David Howells <dhowells@...hat.com>,
	Koichi Yasutake <yasutake.koichi@...panasonic.com>,
	linux-am33-list@...hat.com, Xunlei Pang <pang.xunlei@...aro.org>,
	John Stultz <john.stultz@...aro.org>,
	Arnd Bergmann <arnd@...db.de>
Subject: [PATCH] mn10300: time: Provide 64-bit persistent clock time

From: Xunlei Pang <pang.xunlei@...aro.org>

As part of addressing the "y2038 problem" for in-kernel uses,
convert update_persistent_clock() to update_persistent_clock64(),
read_persistent_clock() to read_persistent_clock64() using
timespec64 for MN10300.

Add the common weak version of update_persistent_clock() to make
the compiler happy, since we don't have any update_persistent_clock()
defined for MN10300 after converting it to update_persistent_clock64().

Cc: John Stultz <john.stultz@...aro.org>
Cc: Arnd Bergmann <arnd@...db.de>
Signed-off-by: Xunlei Pang <pang.xunlei@...aro.org>
---
 arch/mn10300/kernel/rtc.c | 13 ++++++-------
 kernel/time/ntp.c         |  5 +++++
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/arch/mn10300/kernel/rtc.c b/arch/mn10300/kernel/rtc.c
index 48d7058..038ae16 100644
--- a/arch/mn10300/kernel/rtc.c
+++ b/arch/mn10300/kernel/rtc.c
@@ -23,19 +23,19 @@ EXPORT_SYMBOL(rtc_lock);
 /*
  * Read the current RTC time
  */
-void read_persistent_clock(struct timespec *ts)
+void read_persistent_clock64(struct timespec64 *ts)
 {
 	struct rtc_time tm;
 
 	get_rtc_time(&tm);
 
 	ts->tv_nsec = 0;
-	ts->tv_sec = mktime(tm.tm_year, tm.tm_mon, tm.tm_mday,
+	ts->tv_sec = mktime64(tm.tm_year, tm.tm_mon, tm.tm_mday,
 			    tm.tm_hour, tm.tm_min, tm.tm_sec);
 
 	/* if rtc is way off in the past, set something reasonable */
 	if (ts->tv_sec < 0)
-		ts->tv_sec = mktime(2009, 1, 1, 12, 0, 0);
+		ts->tv_sec = mktime64(2009, 1, 1, 12, 0, 0);
 }
 
 /*
@@ -48,7 +48,7 @@ void read_persistent_clock(struct timespec *ts)
  * BUG: This routine does not handle hour overflow properly; it just
  *      sets the minutes. Usually you'll only notice that after reboot!
  */
-static int set_rtc_mmss(unsigned long nowtime)
+static int set_rtc_mmss(time64_t nowtime)
 {
 	unsigned char save_control, save_freq_select;
 	int retval = 0;
@@ -74,8 +74,7 @@ static int set_rtc_mmss(unsigned long nowtime)
 	 * messing with unknown time zones but requires your
 	 * RTC not to be off by more than 15 minutes
 	 */
-	real_seconds = nowtime % 60;
-	real_minutes = nowtime / 60;
+	real_minutes = div_s64_rem(nowtime, 60, &real_seconds);
 	if (((abs(real_minutes - cmos_minutes) + 15) / 30) & 1)
 		/* correct for half hour time zone */
 		real_minutes += 30;
@@ -109,7 +108,7 @@ static int set_rtc_mmss(unsigned long nowtime)
 	return retval;
 }
 
-int update_persistent_clock(struct timespec now)
+int update_persistent_clock64(struct timespec64 now)
 {
 	return set_rtc_mmss(now.tv_sec);
 }
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index fb4d98c..df68cb8 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -487,6 +487,11 @@ out:
 }
 
 #ifdef CONFIG_GENERIC_CMOS_UPDATE
+int __weak update_persistent_clock(struct timespec now)
+{
+	return -ENODEV;
+}
+
 int __weak update_persistent_clock64(struct timespec64 now64)
 {
 	struct timespec now;
-- 
1.9.1


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