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 S1757635AbbJIKeY (ORCPT <rfc822;w@1wt.eu>);
	Fri, 9 Oct 2015 06:34:24 -0400
Received: from mx1.redhat.com ([209.132.183.28]:40164 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1757607AbbJIKeX (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 9 Oct 2015 06:34:23 -0400
Date: Fri, 9 Oct 2015 12:34:21 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Arnd Bergmann <arnd@arndb.de>, linux-kernel@vger.kernel.org,
        y2038@lists.linaro.org, John Stultz <john.stultz@linaro.org>,
        Prarit Bhargava <prarit@redhat.com>,
        Richard Cochran <richardcochran@gmail.com>
Subject: Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t
 overflow
Message-ID: <20151009103421.GC2166@localhost>
References: <1444224137-32510-1-git-send-email-mlichvar@redhat.com>
 <5753784.UXVo9jVTVp@wuerfel>
 <20151008062344.GO5778@localhost>
 <5836683.t4iPTifntz@wuerfel>
 <20151008093923.GQ5778@localhost>
 <alpine.DEB.2.11.1510091032100.6097@nanos>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.11.1510091032100.6097@nanos>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Oct 09, 2015 at 10:46:16AM +0100, Thomas Gleixner wrote:
> On Thu, 8 Oct 2015, Miroslav Lichvar wrote:
> > Applications are not allowed to rely on system time being sane?
> > To me the current behavior looks like the kernel is throwing the
> > applications off a cliff, while it's the only thing that can fly :).
> 
> As Arnd said, you are creating a wrong sense of safety. They fall off
> the cliff with your changes as well. The fall is just different. Think
> about timeouts, user space overflows of time_t etc.

I think vast majority of them won't fall. It doesn't prevent all
problems, but at least the userspace agrees with kernel on what the
current time it is, that looks to me like the most difficult one to
fix in applications.

> We need to fix all of it, no matter what.

Yeah, that would be nice, but I don't think it's realistic.

Do you feel the same about preventing the time from reaching
KTIME_MAX?

-- 
Miroslav Lichvar