From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jesper Nilsson <jesper.nilsson@axis.com>
Subject: Re: [RESEND PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with
 relative timeouts
Date: Tue, 20 Oct 2015 10:59:34 +0200
Message-ID: <20151020085934.GB4919@axis.com>
References: <20151009082514.GY4919@axis.com>
 <CALAqxLVS+NBpz63d3bkQO5yv9gebuotjBdimb2o8X1KitSEqHA@mail.gmail.com>
 <27613722.NGRuyuj3GB@wuerfel>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: John Stultz <john.stultz@linaro.org>,
	Jesper Nilsson <jespern@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>
To: Arnd Bergmann <arnd@arndb.de>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from bastet.se.axis.com ([195.60.68.11]:35799 "EHLO
	bastet.se.axis.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751918AbbJTI7i (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 20 Oct 2015 04:59:38 -0400
Content-Disposition: inline
In-Reply-To: <27613722.NGRuyuj3GB@wuerfel>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Tue, Oct 20, 2015 at 10:18:22AM +0200, Arnd Bergmann wrote:
> 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.

This is how the RTC framework used to handle it before the referenced
patch in my original mail, so a reversal (conditional on 32bit)
would solve that part of the problem.

It also looks like Miroslav's patch will handle the other cases of a
accidental user initiated set of a bad date or a maliciously set NTP.
Though, from my point of view, a wrap-around to 1970 would be just as valid
as a jump one week in the past.

What's the current status of that patch?

> 	Arnd

/^JN - Jesper Nilsson
-- 
               Jesper Nilsson -- jesper.nilsson@axis.com