linux-kernel - Re: hrtimer: one more expiry time overflow check in hrtimer

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

Date:	Fri, 28 Jun 2013 14:22:16 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Shinya Kuribayashi <shinya.kuribayashi.px@...esas.com>
cc:	prarit@...hat.com, john.stultz@...aro.org,
	hiroyuki.yokoyama.vx@...esas.com, takashi.yoshii.zj@...esas.com,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: hrtimer: one more expiry time overflow check in
 hrtimer_interrupt

On Tue, 11 Jun 2013, Shinya Kuribayashi wrote:

> When executing a date command to set the system date and time to a few
> seconds before the 2038 problem expiration time, we got a WARN_ON_ONCE()
> like this:
> 
>   root@...esas:~# date -s "2038-1-19 3:14:00"
>   Tue Jan 19 03:14:00 GMT 2038
>   (then wait for 7-8 seconds)
>   root@...esas:~# [   27.662658] ------------[ cut here ]------------
>   [   27.667297] WARNING: at kernel/time/clockevents.c:209 clockevents_program_event+0x3c/0x138()

> I found a similar issue fixed in v3.9 by Prarit Bhargava in commit
> 8f294b5a13 (hrtimer: Add expiry time overflow check in hrtimer_interrupt,
> 2013-04-08).  It tried to resolve a overflow issue detected around 1970
> + 100 seconds.
> 
> On the other hand, we have another call site of tick_program_event() at
> the bottom of hrtimer_interrupt().  The warning this time is triggered
> there, so we need to apply the same fix to it.

Well, the problem is that you are just papering over the underlying
issue of 32bit systems not being prepared for the year 2038 issue.

Just blindly silencing the warning is not going to make the system
survive 2038 in any sane way. All timespec/val related time functions
dealing with the clock realtime domain are simply broken in 2038 on
32bit, so it does not matter whether a warning triggers or not.
 
We really need to tackle the underlying problem and not bandaiding a
known to be broken system.

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/