Hi Dmitry,

Many thanks for the clarification.

In that case, may I kindly ask if it is necessary to fix joydev with locks,
or we can leave it this way and let it just tolerate some inconsistencies?

Regards,
Ginger

On Tue, Jun 2, 2026 at 1:22 AM Dmitry Torokhov
[off-list ref] wrote:

Hi Ginger,

On Mon, Jun 01, 2026 at 03:07:05PM +0800, Ginger wrote:

quoted

Dear Linux kernel maintainers,

My research-based static analyzer found a potential atomicity bug
within the 'drivers/input' subsystem, more specifically, in
'drivers/input/joydev.c'.

This potential issue is present as of git commit
eb3f4b7426cfd2b79d65b7d37155480b32259a11 of the mainline kernel.

Potential concurrent triggering executions:
T0:
joydev_0x_read
     --> spin_lock_irq(&input->event_lock);
     --> read from joydev->abs
     --> spin_unlock_irq(&input->event_lock);

T1:
joydev_ioctl_common
    --> case JSIOCSCORR:
    --> write to joydev->abs[i] (no unlocked)

The above trace is meant to demonstrate an illustrative example of the issue:
IMHO, in 'joydev_0x_read', the 'input->event_lock' is adopted to
serialize the read
accesses to joydev's fields like 'abs' and 'keypam' or input's fields
like 'input->key.
However, in either case, the write-side accesses to these fields are
not similarly
serialized.

Yes, there is lack of locking in joydev. Some of this might be OK (if
we prevent tearing on reads/writes) since the data may actually be
obsolete immediately after we read it, while in many places we
actually do need consistency, especially when we adjust key and axis
maps.

Thanks.

--
Dmitry