linux-kernel - Re: [PATCH v5 2/3] input: evdev: Replace timeval with timespec64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 2 Jan 2018 16:35:41 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Deepa Dinamani <deepa.kernel@...il.com>,
        "open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Hutterer <peter.hutterer@...-t.net>,
        y2038 Mailman List <y2038@...ts.linaro.org>
Subject: Re: [PATCH v5 2/3] input: evdev: Replace timeval with timespec64

On Tue, Jan 2, 2018 at 7:46 AM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
> On Sun, Dec 17, 2017 at 09:18:43PM -0800, Deepa Dinamani wrote:
>> @@ -304,12 +314,11 @@ static void evdev_events(struct input_handle *handle,
>>  {
>>       struct evdev *evdev = handle->private;
>>       struct evdev_client *client;
>> -     ktime_t ev_time[EV_CLK_MAX];
>> +     struct timespec64 ev_time[EV_CLK_MAX];
>>
>> -     ev_time[EV_CLK_MONO] = ktime_get();
>> -     ev_time[EV_CLK_REAL] = ktime_mono_to_real(ev_time[EV_CLK_MONO]);
>> -     ev_time[EV_CLK_BOOT] = ktime_mono_to_any(ev_time[EV_CLK_MONO],
>> -                                              TK_OFFS_BOOT);
>> +     ktime_get_ts64(&ev_time[EV_CLK_MONO]);
>> +     ktime_get_real_ts64(&ev_time[EV_CLK_REAL]);
>> +     get_monotonic_boottime64(&ev_time[EV_CLK_BOOT]);
>
> This may result in different ev_time[] members holding different times,
> whereas the original code would take one time sample and convert it to
> different clocks.

Is this important? On each client we only return one of the two
times, and I would guess that you cannot rely on a correlation
between timestamps on different devices, since the boot and real
offsets can change over time.

> Also, why can't we keep using ktime_t internally? It is y2038 safe,
> right?

Correct, but there may also be a performance difference if we get
a lot of events, not sure if that matters.

> I think you should drop this patch and adjust the 3rd one to
> massage the input event timestamp patch to do ktime->timespec64->input
> timestamp conversion.

The change in __evdev_queue_syn_dropped still seems useful to me
as ktime_get_*ts64() is a bit more efficient than ktime_get*() followed by
a slow ktime_to_timespec64() or ktime_to_timeval().

For evdev_events(), doing a single ktime_get() followed by a
ktime_to_timespec64/ktime_to_timeval can be faster than three
ktime_get_*ts64 (depending on the hardware clock source), or
it can be slower depending on the CPU and the clocksource
hardware. Again, no idea if this matters at the usual rate of
input events.

I guess dropping the evdev_events() change and replacing it with a
ktime_to_timespec64 change in evdev_pass_values()
would be fine here, it should keep the current performance
behavior and get rid of the timeval.

       Arnd