Re: [PATCH 2/2] input: evdev: Read clock directly in __evdev_queue_syn_dropped()
From: Dmitry Torokhov
Date: Mon Nov 02 2026 - 22:42:34 EST
Hi Kornel,
On Thu, Oct 22, 2026 at 01:39:13PM +0000, Kornel Dulęba wrote:
> Currently, __evdev_queue_syn_dropped() calls input_get_timestamp() on
> the underlying input_dev to obtain the event timestamp. If no timestamp
> is set, input_get_timestamp() caches the current time and returns it;
> otherwise, it returns the cached value.
>
> There are two problems with this approach:
>
> 1. Locking. The timestamp is obtained in the same way in
> evdev_events(), which is called with dev->event_lock held. Calls to
> __evdev_queue_syn_dropped() are only serialized with
> client->buffer_lock. This makes both accesses likely racy.
handler->events() is called under dev->event_lock. I'd love to stop
doing this, this is how it is now.
> 2. If no timestamp is cached yet, the subsequent hardware event
> generated after __evdev_queue_syn_dropped() is called will receive
> the stale cached timestamp.
>
> Fix this by reading the current time directly based on the value of
> client->clk_type. Open-coding this is not the prettiest solution, but I
> couldn't figure out anything better.
>
> I initially thought about fixing this by resetting the input timestamp
> in this function instead, similarly to how INPUT_FLUSH handles it.
> However, I decided against it, as that would require non-trivial
> locking changes.
I wonder if we care about timing on the SYN_DROPPED events? Can we just
grab the dev->timestamp and if it is 0 that's fine. Or not even set the
timestamp at all on SYN_DROPPED and have it always at 0.
What do you think?
Thanks.
--
Dmitry