linux-kernel - Re: [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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <OFD411559C.BD0F55F2-ON48257E8E.000770FE-48257E8E.0008FCBE@zte.com.cn>
Date:	Sun, 26 Jul 2015 09:38:34 +0800
From:	pang.xunlei@....com.cn
To:	John Stultz <john.stultz@...aro.org>
Cc:	Arnd Bergmann <arnd@...db.de>, David Howells <dhowells@...hat.com>,
	linux-am33-list@...hat.com, lkml <linux-kernel@...r.kernel.org>,
	Xunlei Pang <pang.xunlei@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Xunlei Pang <xlpang@....com>,
	Koichi Yasutake <yasutake.koichi@...panasonic.com>
Subject: Re: [PATCH] mn10300: time: Provide 64-bit persistent clock time

Hi John,

John Stultz <john.stultz@...aro.org> wrote 2015-07-25 AM 11:24:32:
> Re: [PATCH] mn10300: time: Provide 64-bit persistent clock time
> 
> On Mon, Jul 20, 2015 at 5:45 PM, Xunlei Pang <xlpang@....com> wrote:
> > 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.
> 
> The arch changes look ok.
> 
> 
> > 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().
> 
> So it wasn't immediately obvious why this was needed (compiler
> unhappiness isn't really a good explanation). Looking at it, it seems
> that the weak update_persistent_clock64() wants a
> update_persistent_clock() call to exist (which probably should have
> been added when the weak update_persistent_clock64 was added). So it
> looks like even if the arch defines a  update_persistent_clock64(),
> the weak one still throws a undefined symbol compiler error, right?
> 
> The weak update_persistent_clock() bit should probably be added in a
> separate patch,  since its not really tied to this arch change (really
> any arch that switches to update_persistent_clock64 would have this
> issue, no?).

Agree, you're absolutely right. Will do.

Thanks,
-Xunlei

> 
> thanks
> -john

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
--
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/