Message-ID: <20180108215111.tqnhr5k5easbrh4b@dtor-ws>
Date:   Mon, 8 Jan 2018 13:51:11 -0800
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Deepa Dinamani <deepa.kernel@...il.com>
Cc:     linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
        peter.hutterer@...-t.net, arnd@...db.de, y2038@...ts.linaro.org
Subject: Re: [PATCH v6 1/1] input: Deprecate real timestamps beyond year 2106

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.

> 
> 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.

> 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.

Thanks!

-- 
Dmitry

Powered by blists - more mailing lists