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 S1753217AbdGCKXt (ORCPT <rfc822;w@1wt.eu>);
        Mon, 3 Jul 2017 06:23:49 -0400
Received: from Galois.linutronix.de ([146.0.238.70]:42764 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752514AbdGCKXq (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 3 Jul 2017 06:23:46 -0400
Date: Mon, 3 Jul 2017 12:23:41 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Arnd Bergmann <arnd@arndb.de>
cc: Deepa Dinamani <deepa.kernel@gmail.com>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        John Stultz <john.stultz@linaro.org>,
        Nicolas Pitre <nicolas.pitre@linaro.org>,
        y2038 Mailman List <y2038@lists.linaro.org>,
        Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v3 0/7] Isolate time_t data types for clock/timer
 syscalls
In-Reply-To: <CAK8P3a3vQqQHcQLB+PfFkzSXY0U2DpB6nTRMq3JWqGkqR-AoFQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1707031219000.2188@nanos>
References: <20170624184508.21500-1-deepa.kernel@gmail.com> <20170626023525.GY10672@ZenIV.linux.org.uk> <CABeXuvpnQJd7-Rxvy599EMsGsrkh5iJavQ76b6AHwwvWp0q2sg@mail.gmail.com> <CAK8P3a3vQqQHcQLB+PfFkzSXY0U2DpB6nTRMq3JWqGkqR-AoFQ@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 26 Jun 2017, Arnd Bergmann wrote:
> On Mon, Jun 26, 2017 at 8:17 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> > On Sun, Jun 25, 2017 at 7:35 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >> On Sat, Jun 24, 2017 at 11:45:01AM -0700, Deepa Dinamani wrote:
> >>> The series aims at isolating data conversions of time_t based structures:
> >>> struct timespec and struct itimerspec at user space boundaries.
> >>> This helps to later change the underlying types to handle y2038 changes
> >>> to these.
> >>
> >> Nice...  A few questions:
> >>
> >> * what about setitimer(2)?  Right now that's the only remaining user of
> >> get_compat_itimerval(); similar for getitimer(2) and put_compat_itimerval().
> >
> > We do not plan to support these beyond y2038 on 32 bit systems.
> > timer_settime() and timer_gettime() are considered to be replacements
> > for these, respectively.
> >
> > There is also going to be a cleanup of timeval/ timespec/ time_t data
> > types and apis after the new syscalls are ready.
> > At that time I might choose to get rid of these itimerval apis. I'm
> > not sure yet.
> 
> I see that internally, alarm/getitimer/setitimer all use ktime_t, so
> one possible solution would be to push down the use of ktime_t
> into the callers and do both the conversion and range check in the
> user copy function.

We still can decide to not support the itimer API with the new y2038 ready
syscalls.

Actually there is no real need to do so because the itimer interfaces are
relative and never absolute. Keeping relative time limited to 68 years from
now should be good enough :)

Thanks,

	tglx