From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753912AbbJTITA (ORCPT <rfc822;w@1wt.eu>);
	Tue, 20 Oct 2015 04:19:00 -0400
Received: from mout.kundenserver.de ([212.227.126.131]:51447 "EHLO
	mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753754AbbJTIS5 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 20 Oct 2015 04:18:57 -0400
From: Arnd Bergmann <arnd@arndb.de>
To: John Stultz <john.stultz@linaro.org>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        lkml <linux-kernel@vger.kernel.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        Michael Kerrisk <mtk@man7.org>, Miroslav Lichvar <mlichvar@redhat.com>,
        Arnd Bergmann <arnd.bergmann@linaro.org>
Subject: Re: [RESEND PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with relative timeouts
Date: Tue, 20 Oct 2015 10:18:22 +0200
Message-ID: <27613722.NGRuyuj3GB@wuerfel>
User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; )
In-Reply-To: <CALAqxLVS+NBpz63d3bkQO5yv9gebuotjBdimb2o8X1KitSEqHA@mail.gmail.com>
References: <20151009082514.GY4919@axis.com> <CALAqxLVS+NBpz63d3bkQO5yv9gebuotjBdimb2o8X1KitSEqHA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Provags-ID: V03:K0:JbXaUIB9bJ72VvraHhT3KvQrjsnBEBtmuZsrWbXFpIvJZhceaXQ
 ogGp5OBDbnzeR4lg1kJJ5UIR2iUXlwVmBhbaAB962wCZwODYTHFeQH2M14lmJHW2ojytGNH
 AXyeJFjoFRL5Z+seTW5Oe0G3QF1Bn8vEEuZoFEO+cRwinBCCJklyE+Tc4kekdJByh1/I3MB
 y1mgFCWjpOFCY8jLhI5hA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:lSkrZVYmf2U=:6aRMFZb9gPu5ACOOjxSsPf
 bEpizEWiTZIbirLCPj+jqxt2i5bXCD/gJ2bWihNcI7uIWA4Z6kGx50Xgeil9z6J+WUF87J+1J
 3gN+VnHYFIbmdOLNdiir+vXe1+ZxawSfGxVLy49jXqBJEk6eFunmMm/3PcJXa+PZhy0rgh8Ax
 D8eXcKLKdyRfPHpGT5Sr0wJvsuwnxt84f5ym3zgRZRH5AsyJUDLWtHvhner17fSIQi9xgbPd+
 GG2MKiA8bG/yHdfU/RwDG/uLchDm1uPHNS9qs25h103Bh6IiP11ov3U8kKi2ce5TNEEOTnFGG
 Whm/5scqzSLIzc7bdzoGzOE+TrkTwOpCytVxIuoWE4Om/AtgIfKN9FCuvZHkTMoDGo89n3tdM
 c58E+GK9wzpQB/oTszYveteVXWJf1IklB+LQZIaBTFYhPLjBobiF2EMYTDLb7qUWqffcQvDL+
 zLyz7l2YfUlZyPchbIotHM3rlIdcy7BJhe4C1qBUqT4pygtKUpeDtSDtYjih1+0wVPHstOFLz
 MKsUvT8KGlXwAGLrMFCh9TDLhnKbQ5T7eyVpfOdQplscyFVgvsteIZL4ERTxsYKOR6NcznZnZ
 LbKUMTvSjsybQUg69xk+gV8hV8UttSpOJ4rRSfRVjmbl9xoNg0pLnP2lkfXksvfIhmDjDzs40
 LoH6nrxfK3feAOkRSIRHieuPUrrQbZinHvCHh1jmsUzTw2Wrf6cQOZPSAANkvKae0UVyte1Ig
 WEnqg5mUn5DR/UQ+
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Monday 19 October 2015 11:53:25 John Stultz wrote:
> 
> But yea. At the same time I get you want to avoid user-pain like in
> the case of the badly initialized RTC, but in that case would
> returning 0 for RTC reads greater then y2038 on 32 bit systems be a
> more sane fix?

I like that idea. In theory we could go further and check that the RTC
is somewhere between 2015 and 2037 (or higher on 64-bit systems) but
return 0 (1970) for anything that is outside of that range. That might
have side-effects for users that have a legitimate reason to backdate
their clocks though.

	Arnd