Re: [PATCH] Input: uinput - fix circular locking dependency with ff-core

[Dmitry Torokhov]

Sorry for disappearing again...

On Mon, Mar 23, 2026 at 10:39:29AM +0500, Mikhail Gavrilov wrote:
> On Mon, Mar 23, 2026 at 10:34 AM Dmitry Torokhov
> <dmitry.torokhov@xxxxxxxxx> 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.

I was talking about taking this new lock in both uinput_request_send()
as well as in uinput_destroy_device() when updating the state. With that
requests_lock will be taken only in uinput_request_alloc_id(),
uinput_request_release_slot(), and uinput_flush_requests().

Thanks.

-- 
Dmitry