Re: [PATCH v6 1/1] input: Deprecate real timestamps beyond year 2106

[Dmitry Torokhov]

On Mon, Jan 08, 2018 at 04:07:22PM -0800, Deepa Dinamani wrote:
> On Mon, Jan 8, 2018 at 1:51 PM, Dmitry Torokhov
> <dmitry.torokhov@xxxxxxxxx> wrote:
> > Hi Deepa,
> >
> > On Sat, Jan 06, 2018 at 04:19:15PM -0800, Deepa Dinamani wrote:
> >> struct timeval is not y2038 safe.
> >> All usage of timeval in the kernel will be replaced by
> >> y2038 safe structures.
> >> The change is also necessary as glibc is introducing support
> >> for 32 bit applications to use 64 bit time_t. Without this
> >> change, many applications would incorrectly interpret values
> >> in the struct input_event.
> >> More details about glibc at
> >> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign .
> >>
> >> struct input_event maintains time for each input event.
> >> Real time timestamps are not ideal for input as this
> >> time can go backwards as noted in the patch a80b83b7b8
> >> by John Stultz. Hence, having the input_event.time fields
> >> only big enough for monotonic and boot times are
> >> sufficient.
> >
> > I am happy with the patch, but have some concerns about changelog. The
> > change does not really prevent anyone from using CLOCK_REALTIME past
> > 2106, especially on 64 bit arches. We are simply extending range of
> > reported seconds in input event by converting from signed to unsigned
> > value.
> 
> I was interpreting working incorrectly on 32 bit architectures, but
> working correctly on 64 bit architectures as a failure of the feature
> to use realtime clock at all.
> But, you are correct that the patch does not actively do anything to
> stop people from using realtime clock.
> 
> >>
> >> The change leaves the representation of struct input_event as is
> >> on 64 bit architectures. But uses 2 unsigned long values on 32 bit
> >> machines to support real timestamps until year 2106.
> >> This intentionally breaks the ABI on 32 bit architectures and
> >> compat handling on 64 bit architectures.
> >> This is as per maintainer's preference to introduce compile time errors
> >> rather than run into runtime incompatibilities.
> >
> > We are breaking API, not ABI though. The ABI for existing programs is
> > exactly the same, it is only when system starts using the newer glibc
> > supporting extended time the compilation will break.
> 
> I was interpreting not being able to use negative timestamps on 32 bit
> machines as breaking the ABI.
> 
> >> The change requires any 32 bit userspace utilities reading or writing
> >> from event nodes to update their reading format to match the new
> >> input_event. The changes to the popular libraries will be posted once
> >> we agree on the kernel change.
> > I propose we have the following changelog:
> >
> >
> > Input: extend usable life of event timestamps to 2106 on 32 bit systems
> >
> > The input events use struct timeval to store event time, unfortunately
> > this structure is not y2038 safe and is being replaced in kernel with
> > y2038 safe structures.
> >
> > Because of ABI concerns we can not change the size or the layout of
> > structure input_event, so we opt to re-interpreting the 'seconds' part
> > of timestamp as an unsigned value, effectively doubling the range of
> > values, to year 2106.
> > Newer glibc that has support for 32 bit applications to use 64 bit
> > time_t supplies __USE_TIME_BITS64 define [1], that we can use to present
> > the userspace with updated input_event layout. The updated layout will
> > cause the compile time breakage, alerting applications and distributions
> > maintainers to the issue. Existing 32 binaries will continue working
> > without any changes until 2038.
> >
> > Ultimately userspace applications should switch to using monotonic or
> > boot time clocks, as realtime clock is not very well suited for input
> > event timestamps as it can go backwards (see a80b83b7b8 "Input: evdev -
> > add CLOCK_BOOTTIME support" by by John Stultz). With monotonic clock the
> > practical range of reported times will always fit into the pair of 32
> > bit values, as we do not expect any system to stay up for a hundred
> > years without a single reboot.
> >
> > [1] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
> >
> >
> > Please let me know if you disagee with the above.
> 
> I'm fine with this commit text. Let me know if you would like me to update this.

No, unless somebody yells I'll change it on my side.

Thanks.

-- 
Dmitry