Re: [PATCH v2 2/4] Input: clear inhibited flag before re-opening device on uninhibit

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] When `dev->open()` fails during uninhibiting, restoring `dev->inhibited = true` without holding `dev->event_lock` and without releasing active keys leaves events permanently stuck in userspace.
--

--- Patch [2]: [PATCH v2 2/4] Input: clear inhibited flag before re-opening device on uninhibit ---
commit f055731a6a02bc8698a040a5af7e51e9039340a7
Author: Dmitry Torokhov <[email protected]>

Input: clear inhibited flag before re-opening device on uninhibit

This patch clears dev->inhibited before calling dev->open() when
uninhibiting a device. It ensures initial events are delivered to handlers,
and restores dev->inhibited if dev->open() fails.

> diff --git a/drivers/input/input.c b/drivers/input/input.c
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -1813,24 +1813,26 @@ static int input_uninhibit_device(struct input_dev *dev)
>  	if (!dev->inhibited)
>  		return 0;
>  
> +	dev->inhibited = false;
> +
>  	if (dev->users) {
>  		if (dev->open) {
>  			error = dev->open(dev);
> -			if (error)
> +			if (error) {
> +				dev->inhibited = true;

[Severity: Medium]
When dev->open() fails and dev->inhibited is restored to true, is there a
potential data race with concurrent input_handle_event() readers?

Since dev->inhibited was set to false earlier, the driver's open() method or
interrupts could have emitted events before the failure. Does restoring
dev->inhibited here without holding dev->event_lock and without synthesizing
key releases via input_dev_release_keys() risk leaving events permanently
stuck in userspace?

>  				return error;
> +			}
>  		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2