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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 28 Nov 2014 00:28:16 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Arnd Bergmann <arnd@...db.de>
cc:	Xunlei Pang <pang.xunlei@...aro.org>, linux-kernel@...r.kernel.org,
	rtc-linux@...glegroups.com,
	Alessandro Zummo <a.zummo@...ertech.it>,
	Sven Schnelle <svens@...ckframe.org>,
	John Stultz <john.stultz@...aro.org>,
	Arnd Bergmann <arnd.bergmann@...aro.org>
Subject: Re: [RFC PATCH 2/4] rtc: Convert rtc_class_ops.set_mmss() to use
 time64_t

On Fri, 28 Nov 2014, Arnd Bergmann wrote:
> On Friday 28 November 2014 00:05:34 Thomas Gleixner wrote:
> > On Thu, 27 Nov 2014, Xunlei Pang wrote:
> > > -static int coh901331_set_mmss(struct device *dev, unsigned long secs)
> > > +static int coh901331_set_mmss(struct device *dev, time64_t secs)
> > >  {
> > >       struct coh901331_port *rtap = dev_get_drvdata(dev);
> > >  
> > >       clk_enable(rtap->clk);
> > > +     /*
> > > +      * y2106 issue:
> > > +      *   On 32bit systems the time64_t secs value gets cast to
> > > +      *   a 32bit long, and thus we can only write a maximum value
> > > +      *   of y2016
> > 
> > That really makes a lot of sense. Before that patch the driver was
> > safe up to 2038. Now it is facing the y2016 problem.
> 
> Actually the comment is still wrong with the number fixed, I hadn't
> noticed when I looked at the patch earlier:
> 
> The cast happens on both 32-bit and 64-bit, as we cast into a u32
> value through the writel(). The behavior of this driver doesn't
> even change with this patch, it was good until y2106 and stays
> that way because 'unsigned long', 'time64_t' and 'u32' can all represent
> at least times between 1970 and 2106, the change is just to document
> the time at which it will break, while changing the API.

Indeed. I did not bother to think about that as I was already in
grumpy mode due to the general aproach of creating the maximal churn
for no value.
 
Thanks,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ