From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Input: uinput - fix circular locking dependency with ff-core
Date: Sun, 22 Mar 2026 22:34:30 -0700 [thread overview]
Message-ID: <acDPeFpxX57Uu0Mm@google.com> (raw)
In-Reply-To: <CABXGCsOwJu2dw67bR38MJb5DFvGon=MUCxKcGEQYfT6qrPZU1w@mail.gmail.com>
On Mon, Mar 23, 2026 at 10:17:01AM +0500, Mikhail Gavrilov wrote:
> On Mon, Mar 23, 2026 at 7:47 AM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > Thank you for the patch, it looks solid, however I wonder if creating a
> > separate "state_lock" spinlock would not be better than reusing
> > requests_lock?
>
> Hi Dmitry,
>
> Thank you for the review.
>
> A separate spinlock would certainly be cleaner from a naming
> perspective. One thing I'd like to note though: the current
> approach of reusing requests_lock has the benefit of atomically
> checking state and queueing the event in uinput_request_send(),
> and atomically changing state and flushing requests in
> uinput_destroy_device(). With a separate state_lock these become
> two independent locks, so the ordering between them would need to
> be defined.
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?
Thanks.
--
Dmitry
next prev parent reply other threads:[~2026-03-23 5:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-28 22:36 [PATCH] Input: uinput - fix circular locking dependency with ff-core Mikhail Gavrilov
2026-03-11 17:47 ` mikhail.v.gavrilov
2026-03-11 17:50 ` Dmitry Torokhov
2026-03-23 2:47 ` Dmitry Torokhov
2026-03-23 5:17 ` Mikhail Gavrilov
2026-03-23 5:34 ` Dmitry Torokhov [this message]
2026-03-23 5:39 ` Mikhail Gavrilov
2026-04-07 5:19 ` Dmitry Torokhov
2026-04-07 8:39 ` Mikhail Gavrilov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=acDPeFpxX57Uu0Mm@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikhail.v.gavrilov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.