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

On Mon, Aug 03, 2026 at 01:18:32AM +0000, [email protected] wrote:
> 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?

Userspace has to clean up its own state after a device disappears.

Thanks.

-- 
Dmitry