* [PATCH v6 0/1] Make input drivers y2038 safe @ 2018-01-07 0:19 Deepa Dinamani 2018-01-07 0:19 ` [PATCH v6 1/1] input: Deprecate real timestamps beyond year 2106 Deepa Dinamani 0 siblings, 1 reply; 5+ messages in thread From: Deepa Dinamani @ 2018-01-07 0:19 UTC (permalink / raw) To: dmitry.torokhov, linux-input, linux-kernel; +Cc: y2038, peter.hutterer, arnd The series is aimed at making input events y2038 safe. It extends the lifetime of the realtime timestamps in the events to year 2106. The series is also a necessary update as glibc is set to provide 64 bit time_t support for 32 bit binaries. glibc plan is detailed at https://sourceware.org/glibc/wiki/Y2038ProofnessDesign . The series is a result of discussions with Arnd Bergmann and Dmitry Torokhov at last Plumbers. The plan is to deprecate realtime timestamps anyway as they are not appropriate for these timestamps as noted in the patch a80b83b7b8 by John Stultz. The design also updates the format of the input events read/ written to the device nodes. This breaks 32 bit interface to the input events at compile time as preferred by the maintainer. The userspace library changes to libevdev, libuinput and mtdev will be posted to the respective mailing groups for review. Changes from v5: * Dropped patch 1, since it has already been applied * Combined patches 2 and 3 * Addressed minor review comments Changes from v4: * Dropped serio hil patch Changes from v3: * Updated uinput to support monotonic time only * Addressed review comments Changes from v2: * Updated the design to break 32 bit interfaces at compile time. Changes from v1: * Updated changes according to review comments. * Posted userspace library changes that go along with the series. Deepa Dinamani (1): input: Deprecate real timestamps beyond year 2106 drivers/input/evdev.c | 16 ++++++++++++---- drivers/input/input-compat.c | 8 ++++---- drivers/input/input-compat.h | 3 ++- drivers/input/misc/uinput.c | 4 ++-- include/uapi/linux/input.h | 12 +++++++++++- 5 files changed, 31 insertions(+), 12 deletions(-) base-commit: 0c1f9d81ac360d8ad31cbfd2bdcf44de8204188e prerequisite-patch-id: 6c903c00c9d5191619efe9f26e2600197336e6b2 -- 2.14.1 _______________________________________________ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v6 1/1] input: Deprecate real timestamps beyond year 2106 2018-01-07 0:19 [PATCH v6 0/1] Make input drivers y2038 safe Deepa Dinamani @ 2018-01-07 0:19 ` Deepa Dinamani 2018-01-08 21:51 ` Dmitry Torokhov 0 siblings, 1 reply; 5+ messages in thread From: Deepa Dinamani @ 2018-01-07 0:19 UTC (permalink / raw) To: dmitry.torokhov, linux-input, linux-kernel; +Cc: peter.hutterer, arnd, y2038 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. 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. 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. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> --- drivers/input/evdev.c | 16 ++++++++++++---- drivers/input/input-compat.c | 8 ++++---- drivers/input/input-compat.h | 3 ++- drivers/input/misc/uinput.c | 4 ++-- include/uapi/linux/input.h | 12 +++++++++++- 5 files changed, 31 insertions(+), 12 deletions(-) diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c index 0193dd4f0452..8a8a905ab886 100644 --- a/drivers/input/evdev.c +++ b/drivers/input/evdev.c @@ -135,7 +135,8 @@ static void __evdev_flush_queue(struct evdev_client *client, unsigned int type) continue; } else if (head != i) { /* move entry to fill the gap */ - client->buffer[head].time = ev->time; + client->buffer[head].input_event_sec = ev->input_event_sec; + client->buffer[head].input_event_usec = ev->input_event_usec; client->buffer[head].type = ev->type; client->buffer[head].code = ev->code; client->buffer[head].value = ev->value; @@ -157,6 +158,7 @@ static void __evdev_queue_syn_dropped(struct evdev_client *client) { struct input_event ev; ktime_t time; + struct timespec64 ts; time = client->clk_type == EV_CLK_REAL ? ktime_get_real() : @@ -164,7 +166,9 @@ static void __evdev_queue_syn_dropped(struct evdev_client *client) ktime_get() : ktime_get_boottime(); - ev.time = ktime_to_timeval(time); + ts = ktime_to_timespec64(time); + ev.input_event_sec = ts.tv_sec; + ev.input_event_usec = ts.tv_nsec / NSEC_PER_USEC; ev.type = EV_SYN; ev.code = SYN_DROPPED; ev.value = 0; @@ -241,7 +245,8 @@ static void __pass_event(struct evdev_client *client, */ client->tail = (client->head - 2) & (client->bufsize - 1); - client->buffer[client->tail].time = event->time; + client->buffer[client->tail].input_event_sec = event->input_event_sec; + client->buffer[client->tail].input_event_usec = event->input_event_usec; client->buffer[client->tail].type = EV_SYN; client->buffer[client->tail].code = SYN_DROPPED; client->buffer[client->tail].value = 0; @@ -262,12 +267,15 @@ static void evdev_pass_values(struct evdev_client *client, struct evdev *evdev = client->evdev; const struct input_value *v; struct input_event event; + struct timespec64 ts; bool wakeup = false; if (client->revoked) return; - event.time = ktime_to_timeval(ev_time[client->clk_type]); + ts = ktime_to_timespec64(ev_time[client->clk_type]); + event.input_event_sec = ts.tv_sec; + event.input_event_usec = ts.tv_nsec / NSEC_PER_USEC; /* Interrupts are disabled, just acquire the lock. */ spin_lock(&client->buffer_lock); diff --git a/drivers/input/input-compat.c b/drivers/input/input-compat.c index 2186f71c9fe5..fda8d6d2a268 100644 --- a/drivers/input/input-compat.c +++ b/drivers/input/input-compat.c @@ -24,8 +24,8 @@ int input_event_from_user(const char __user *buffer, sizeof(struct input_event_compat))) return -EFAULT; - event->time.tv_sec = compat_event.time.tv_sec; - event->time.tv_usec = compat_event.time.tv_usec; + event->input_event_sec = compat_event.sec; + event->input_event_usec = compat_event.usec; event->type = compat_event.type; event->code = compat_event.code; event->value = compat_event.value; @@ -44,8 +44,8 @@ int input_event_to_user(char __user *buffer, if (in_compat_syscall() && !COMPAT_USE_64BIT_TIME) { struct input_event_compat compat_event; - compat_event.time.tv_sec = event->time.tv_sec; - compat_event.time.tv_usec = event->time.tv_usec; + compat_event.sec = event->input_event_sec; + compat_event.usec = event->input_event_usec; compat_event.type = event->type; compat_event.code = event->code; compat_event.value = event->value; diff --git a/drivers/input/input-compat.h b/drivers/input/input-compat.h index 1563160a7af3..08cd755e73fd 100644 --- a/drivers/input/input-compat.h +++ b/drivers/input/input-compat.h @@ -18,7 +18,8 @@ #ifdef CONFIG_COMPAT struct input_event_compat { - struct compat_timeval time; + compat_ulong_t sec; + compat_ulong_t usec; __u16 type; __u16 code; __s32 value; diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c index 9251765645d1..03d22fc90a45 100644 --- a/drivers/input/misc/uinput.c +++ b/drivers/input/misc/uinput.c @@ -90,8 +90,8 @@ static int uinput_dev_event(struct input_dev *dev, udev->buff[udev->head].code = code; udev->buff[udev->head].value = value; ktime_get_ts64(&ts); - udev->buff[udev->head].time.tv_sec = ts.tv_sec; - udev->buff[udev->head].time.tv_usec = ts.tv_nsec / NSEC_PER_USEC; + udev->buff[udev->head].input_event_sec = ts.tv_sec; + udev->buff[udev->head].input_event_usec = ts.tv_nsec / NSEC_PER_USEC; udev->head = (udev->head + 1) % UINPUT_BUFFER_SIZE; wake_up_interruptible(&udev->waitq); diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h index 8c5a0bf6ee35..9c5105ff5cc6 100644 --- a/include/uapi/linux/input.h +++ b/include/uapi/linux/input.h @@ -21,10 +21,20 @@ /* * The event structure itself + * Note that __USE_TIME_BITS64 is defined by libc based on + * application's request to use 64 bit time_t. */ - struct input_event { +#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) && !defined(__KERNEL) struct timeval time; +#define input_event_sec time.tv_sec +#define input_event_usec time.tv_usec +#else + __kernel_ulong_t __sec; + __kernel_ulong_t __usec; +#define input_event_sec __sec +#define input_event_usec __usec +#endif __u16 type; __u16 code; __s32 value; -- 2.14.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v6 1/1] input: Deprecate real timestamps beyond year 2106 2018-01-07 0:19 ` [PATCH v6 1/1] input: Deprecate real timestamps beyond year 2106 Deepa Dinamani @ 2018-01-08 21:51 ` Dmitry Torokhov 2018-01-09 0:07 ` Deepa Dinamani 0 siblings, 1 reply; 5+ messages in thread From: Dmitry Torokhov @ 2018-01-08 21:51 UTC (permalink / raw) To: Deepa Dinamani; +Cc: y2038, peter.hutterer, linux-kernel, arnd, linux-input 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 _______________________________________________ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v6 1/1] input: Deprecate real timestamps beyond year 2106 2018-01-08 21:51 ` Dmitry Torokhov @ 2018-01-09 0:07 ` Deepa Dinamani 2018-01-09 0:32 ` Dmitry Torokhov 0 siblings, 1 reply; 5+ messages in thread From: Deepa Dinamani @ 2018-01-09 0:07 UTC (permalink / raw) To: Dmitry Torokhov Cc: y2038 Mailman List, Peter Hutterer, Linux Kernel Mailing List, Arnd Bergmann, open list:HID CORE LAYER On Mon, Jan 8, 2018 at 1:51 PM, Dmitry Torokhov <dmitry.torokhov@gmail.com> 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. Thanks, Deepa _______________________________________________ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v6 1/1] input: Deprecate real timestamps beyond year 2106 2018-01-09 0:07 ` Deepa Dinamani @ 2018-01-09 0:32 ` Dmitry Torokhov 0 siblings, 0 replies; 5+ messages in thread From: Dmitry Torokhov @ 2018-01-09 0:32 UTC (permalink / raw) To: Deepa Dinamani Cc: open list:HID CORE LAYER, Linux Kernel Mailing List, Peter Hutterer, Arnd Bergmann, y2038 Mailman List 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@gmail.com> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-01-09 0:32 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-01-07 0:19 [PATCH v6 0/1] Make input drivers y2038 safe Deepa Dinamani 2018-01-07 0:19 ` [PATCH v6 1/1] input: Deprecate real timestamps beyond year 2106 Deepa Dinamani 2018-01-08 21:51 ` Dmitry Torokhov 2018-01-09 0:07 ` Deepa Dinamani 2018-01-09 0:32 ` Dmitry Torokhov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).