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. Thanks, Deepa -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
