From: Avichal Rakesh <arakesh@google.com>
To: Michael Grzeschik <mgr@pengutronix.de>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Daniel Scally <dan.scally@ideasonboard.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
jchowdhary@google.com, etalvala@google.com,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 0/3] usb: gadget: uvc: stability fixes on STREAMOFF.
Date: Wed, 11 Oct 2023 17:33:46 -0700 [thread overview]
Message-ID: <26747e41-6848-493d-a442-abedea09b751@google.com> (raw)
In-Reply-To: <ZSMHeH6jNtXMRR2K@pengutronix.de>
On 10/8/23 12:48, Michael Grzeschik wrote:
> On Fri, Oct 06, 2023 at 04:48:19PM -0700, Avichal Rakesh wrote:
>> On 10/6/23 15:53, Michael Grzeschik wrote:
>>> On Fri, Oct 06, 2023 at 10:00:11AM -0700, Avichal Rakesh wrote:
>>>>
>>>>
>>>> On 10/5/23 15:05, Michael Grzeschik wrote:
>>>>> Hi Avichal,
>>>>>
>>>>> On Thu, Oct 05, 2023 at 11:30:32AM -0700, Avichal Rakesh wrote:
>>>>>> On 10/5/23 03:14, Michael Grzeschik wrote:
>>>>> <snip>
>>>>> I don't know where the extra complexity comes from.
>>>>
>>>> A lot of this complexity comes from assuming a back to back
>>>> STREAMOFF -> STREAMON sequence is possible where the gadget driver
>>>> doesn't have the time to clean up all in-flight usb_requests.
>>>> However, looking through the usb gadget APIs again, and it
>>>> looks like usb_ep_disable enforces that all requests will
>>>> be sent back to the gadget driver before it returns.
>>>
>>> Great!
>>
>> Uhh...apologies, I will have to take this back. I've been
>> trying to use uvc->state as the condition for when completion
>> handler should clean up usb_requests, and I cannot figure
>> out a way to do so cleanly.
>>
>> The fundamental problem with using uvc->state is that it is
>> not protected by any locks. So there is no real way to
>> assert that its value has not changed between reading
>> uvc->state and acting on it.
>>
>> Naively we can write something like the following in the
>> completion handler:
>>
>> void uvc_video_complete(...) {
>> if (uvc->state != UVC_EVENT_STREAMING) {
>> usb_ep_free_request(....);
>> } else {
>> // handle usb_request normally
>> }
>> }
>>
>> But without any locks, there are no guarantees that
>> uvc->state didn't mutate immediately after the if
>> condition was checked, and the complete handler is
>> handling a request that it should've freed instead
>> or vice-versa. This argument would hold for any logic
>> we guard with uvc->state, making uvc->state effectively
>> useless as a check for freeing memory.
>
> Yes, this makes total sense. Since the above condition was also part of
> the wait_event patch you created in the first place, I bet this issue
> was there aswell and was probably causing the issues I saw while testing
> it>
>
>> We can work around it by either
>> 1. Locking uvc->state with some driver level lock
>> to ensure that we can trust the value of uvc->state
>> at least for a little while, or
>> 2. Using some other barrier condition that is protected by
>> another lock
>>
>> If we go with (1), we'd have to add a lock around every
>> and every write to uvc->state, which isn't terrible, but
>> would require more testing to ensure that it doesn't
>> create any new deadlocks.
>>
>> For (2), with the realization that usb_ep_disable flushes
>> all requests, we can add a barrier in uvc_video, protected by
>> req_lock. That should simplify the logic a little bit and
>> will hopefully be easier to reason about.
>>
>> I could of course be missing a simpler solution here,
>> and am happy to be wrong. So please let me know if you
>> have any other ideas on how to guarantee such a check.
>
> For now, I have no better Idea. Idea (2) sounds like
> a good compromise. But I will have to review that code
> to really judge.
>
Sent out v4 patches with option (2). It simplifies the logic
decently because we no longer have to reason about per-request
consistency. uvc_video now tracks its own state of whether
requests should be flowing or not based on calls to
uvcg_video_enable. This state is protected, and is the source
of truth for queueing usb_requests.
The last bit of complexity left is around returning in-flight
video buffers. AFAICT it should now be protected, and in my
local testing I didn't notice any un-returned buffers, but
please to take a look and let me know if your testing
uncovers anything.
Thanks,
Avi.
next prev parent reply other threads:[~2023-10-12 0:33 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-30 18:48 [PATCH v1 0/3] usb: gadget: uvc: stability fixes on STREAMOFF Avichal Rakesh
2023-09-30 18:48 ` [PATCH v1 1/3] usb: gadget: uvc: prevent use of disabled endpoint Avichal Rakesh
2023-10-03 23:18 ` [PATCH v2 " Avichal Rakesh
2023-09-30 18:48 ` [PATCH v1 2/3] usb: gadget: uvc: Allocate uvc_requests one at a time Avichal Rakesh
2023-10-03 23:19 ` [PATCH v2 " Avichal Rakesh
2023-09-30 18:48 ` [PATCH v1 3/3] usb: gadget: uvc: Fix use-after-free for inflight usb_requests Avichal Rakesh
2023-10-03 23:21 ` [PATCH v2 " Avichal Rakesh
2023-10-03 11:09 ` [PATCH v1 0/3] usb: gadget: uvc: stability fixes on STREAMOFF Michael Grzeschik
2023-10-03 23:16 ` Avichal Rakesh
2023-10-05 7:11 ` Greg Kroah-Hartman
2023-10-05 18:09 ` Avichal Rakesh
2023-10-05 8:23 ` Laurent Pinchart
2023-10-05 10:14 ` Michael Grzeschik
2023-10-05 18:30 ` Avichal Rakesh
2023-10-05 22:05 ` Michael Grzeschik
2023-10-06 17:00 ` Avichal Rakesh
2023-10-06 22:53 ` Michael Grzeschik
2023-10-06 23:48 ` Avichal Rakesh
2023-10-08 19:48 ` Michael Grzeschik
2023-10-12 0:33 ` Avichal Rakesh [this message]
2023-10-05 18:08 ` [PATCH v3 1/3] usb: gadget: uvc: prevent use of disabled endpoint Avichal Rakesh
2023-10-05 18:08 ` [PATCH v3 2/3] usb: gadget: uvc: Allocate uvc_requests one at a time Avichal Rakesh
2023-10-06 22:11 ` Michael Grzeschik
2023-10-05 18:08 ` [PATCH v3 3/3] usb: gadget: uvc: Fix use-after-free for inflight usb_requests Avichal Rakesh
2023-10-06 22:04 ` [PATCH v3 1/3] usb: gadget: uvc: prevent use of disabled endpoint Michael Grzeschik
2023-10-12 0:24 ` [PATCH v4 " Avichal Rakesh
2023-10-12 0:24 ` [PATCH v4 2/3] usb: gadget: uvc: Allocate uvc_requests one at a time Avichal Rakesh
2023-10-18 13:03 ` Michael Grzeschik
2023-10-18 19:53 ` Avichal Rakesh
2023-10-12 0:24 ` [PATCH v4 3/3] usb: gadget: uvc: Fix use-after-free for inflight usb_requests Avichal Rakesh
2023-10-12 0:42 ` Avichal Rakesh
2023-10-18 13:10 ` Michael Grzeschik
2023-10-18 21:50 ` Avichal Rakesh
2023-10-18 22:06 ` Michael Grzeschik
2023-10-19 18:54 ` Avichal Rakesh
2023-10-18 19:46 ` [PATCH v5 1/3] usb: gadget: uvc: prevent use of disabled endpoint Avichal Rakesh
2023-10-18 19:46 ` [PATCH v5 2/3] usb: gadget: uvc: Allocate uvc_requests one at a time Avichal Rakesh
2023-10-18 19:46 ` [PATCH v5 3/3] usb: gadget: uvc: Fix use-after-free for inflight usb_requests Avichal Rakesh
2023-10-19 18:53 ` [PATCH v6 0/4] usb: gadget: uvc: stability fixes on STREAMOFF Avichal Rakesh
2023-10-19 18:53 ` [PATCH v6 1/4] usb: gadget: uvc: prevent use of disabled endpoint Avichal Rakesh
2023-10-19 18:53 ` [PATCH v6 2/4] usb: gadget: uvc: Allocate uvc_requests one at a time Avichal Rakesh
2023-10-19 18:53 ` [PATCH v6 3/4] usb: gadget: uvc: move video disable logic to its own function Avichal Rakesh
2023-10-19 18:53 ` [PATCH v6 4/4] usb: gadget: uvc: Fix use-after-free for inflight usb_requests Avichal Rakesh
2023-10-19 20:32 ` kernel test robot
2023-10-19 22:30 ` Avichal Rakesh
2023-10-21 10:05 ` Greg KH
2023-10-23 21:25 ` Avichal Rakesh
2023-10-24 9:27 ` Greg KH
2023-10-24 20:00 ` Avichal Rakesh
2023-10-19 18:59 ` [PATCH v6 0/4] usb: gadget: uvc: stability fixes on STREAMOFF Avichal Rakesh
2023-10-27 20:19 ` [PATCH v9 1/4] usb: gadget: uvc: prevent use of disabled endpoint Avichal Rakesh
2023-10-27 20:19 ` [PATCH v9 2/4] usb: gadget: uvc: Allocate uvc_requests one at a time Avichal Rakesh
2023-10-28 10:31 ` Greg KH
2023-10-28 20:13 ` Dan Scally
2023-10-30 20:26 ` Avichal Rakesh
2023-10-27 20:19 ` [PATCH v9 3/4] usb: gadget: uvc: move video disable logic to its own function Avichal Rakesh
2023-10-28 20:16 ` Dan Scally
2023-10-27 20:19 ` [PATCH v9 4/4] usb: gadget: uvc: Fix use-after-free for inflight usb_requests Avichal Rakesh
2023-10-28 20:56 ` Dan Scally
2023-10-30 20:56 ` Avichal Rakesh
2023-11-02 13:29 ` Dan Scally
2023-11-02 20:39 ` Avichal Rakesh
2023-11-07 21:15 ` Avichal Rakesh
2023-10-30 20:22 ` [PATCH v10 1/4] usb: gadget: uvc: prevent use of disabled endpoint Avichal Rakesh
2023-10-30 20:22 ` [PATCH v10 2/4] usb: gadget: uvc: Allocate uvc_requests one at a time Avichal Rakesh
2023-11-01 11:06 ` Dan Scally
2023-11-01 22:13 ` Avichal Rakesh
2023-11-02 11:38 ` Dan Scally
2023-10-30 20:22 ` [PATCH v10 3/4] usb: gadget: uvc: move video disable logic to its own function Avichal Rakesh
2023-10-30 20:22 ` [PATCH v10 4/4] usb: gadget: uvc: Fix use-after-free for inflight usb_requests Avichal Rakesh
2023-11-02 20:19 ` [PATCH v11 1/4] usb: gadget: uvc: prevent use of disabled endpoint Avichal Rakesh
2023-11-02 20:19 ` [PATCH v11 2/4] usb: gadget: uvc: Allocate uvc_requests one at a time Avichal Rakesh
2023-11-02 20:19 ` [PATCH v11 3/4] usb: gadget: uvc: move video disable logic to its own function Avichal Rakesh
2023-11-02 20:19 ` [PATCH v11 4/4] usb: gadget: uvc: Fix use-after-free for inflight usb_requests Avichal Rakesh
2023-11-08 14:15 ` Dan Scally
2023-11-09 1:00 ` Avichal Rakesh
2023-11-09 0:41 ` [PATCH v12 1/4] usb: gadget: uvc: prevent use of disabled endpoint Avichal Rakesh
2023-11-09 0:41 ` [PATCH v12 2/4] usb: gadget: uvc: Allocate uvc_requests one at a time Avichal Rakesh
2023-11-09 0:41 ` [PATCH v12 3/4] usb: gadget: uvc: move video disable logic to its own function Avichal Rakesh
2023-11-09 0:41 ` [PATCH v12 4/4] usb: gadget: uvc: Fix use-after-free for inflight usb_requests Avichal Rakesh
2023-11-14 21:04 ` [PATCH v12 1/4] usb: gadget: uvc: prevent use of disabled endpoint Avichal Rakesh
2023-10-20 17:36 ` [PATCH v7 " Avichal Rakesh
2023-10-20 17:36 ` [PATCH v7 2/4] usb: gadget: uvc: Allocate uvc_requests one at a time Avichal Rakesh
2023-10-20 17:36 ` [PATCH v7 3/4] usb: gadget: uvc: move video disable logic to its own function Avichal Rakesh
2023-10-20 17:36 ` [PATCH v7 4/4] usb: gadget: uvc: Fix use-after-free for inflight usb_requests Avichal Rakesh
2023-10-24 18:36 ` [PATCH v8 1/4] usb: gadget: uvc: prevent use of disabled endpoint Avichal Rakesh
2023-10-24 18:36 ` [PATCH v8 2/4] usb: gadget: uvc: Allocate uvc_requests one at a time Avichal Rakesh
[not found] ` <421d1996-8544-45ac-9f31-551ef597546c@ideasonboard.com>
2023-10-27 20:31 ` Avichal Rakesh
2023-10-28 5:30 ` Greg KH
2023-10-24 18:36 ` [PATCH v8 3/4] usb: gadget: uvc: move video disable logic to its own function Avichal Rakesh
2023-10-24 18:36 ` [PATCH v8 4/4] usb: gadget: uvc: Fix use-after-free for inflight usb_requests Avichal Rakesh
2023-10-26 20:23 ` [PATCH v8 1/4] usb: gadget: uvc: prevent use of disabled endpoint Avichal Rakesh
2023-10-27 10:51 ` Greg KH
2023-10-27 10:52 ` Dan Scally
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=26747e41-6848-493d-a442-abedea09b751@google.com \
--to=arakesh@google.com \
--cc=dan.scally@ideasonboard.com \
--cc=etalvala@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=jchowdhary@google.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mgr@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).