Re: [PATCH 2/2] input: evdev: Read clock directly in __evdev_queue_syn_dropped()

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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