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 [off-list ref]

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.

quoted

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?