On Mon, Mar 23, 2026 at 10:34 AM Dmitry Torokhov
[off-list ref] wrote:
Hmm, I am not sure I see the issue. We are not going to change state
back to UIST_CREATED until after uinput_destroy_device() returns so we
will not submit more requests...
What am I missing?
You are right, there is no lock ordering issue since the state
transition is one-way.
The reason I reused requests_lock is that uinput_request_send()
needs to atomically check state and access udev->dev. If we use a
separate state_lock and release it before calling
uinput_dev_event(), uinput_destroy_device() could run in between,
unregister the device, and we'd hit a use-after-free on udev->dev.
A separate lock would need to be held across the same scope,
making it functionally equivalent to reusing requests_lock.
--
Best Regards,
Mike Gavrilov.