kernel/drivers/usb/gadget/function/uvc_video.c, branch linux-6.9.y

usb: gadget: uvc: mark incomplete frames with UVC_STREAM_ERR

2024-02-17T16:08:45Z

If an frame was transmitted incomplete to the host, we set the UVC_STREAM_ERR bit in the header for the last request that is going to be queued. This way the host will know that it should drop the frame instead of trying to display the corrupted content. Signed-off-by: Michael Grzeschik Link: https://lore.kernel.org/r/20240214-uvc-error-tag-v1-2-37659a3877fe@pengutronix.de Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: dont drop frames if zero length packages are late

2024-02-17T16:08:45Z

If the request that was missed was zero bytes long, it is likely that the overall transferred frame was not affected. So don't flag the frame incomplete in that case. Signed-off-by: Michael Grzeschik Link: https://lore.kernel.org/r/20240214-uvc-error-tag-v1-1-37659a3877fe@pengutronix.de Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: rework complete handler

2024-02-17T16:08:30Z

We refactor the complete handler since the return path with the locking are really difficult to follow. Just simplify the function by switching the logic return it on an disabled endpoint early. This way the second level of indentation can be removed. Signed-off-by: Michael Grzeschik Link: https://lore.kernel.org/r/20240214-uvc-gadget-cleanup-v1-3-de6d78780459@pengutronix.de Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: refactor the check for a valid buffer in the pump worker

2024-02-17T16:08:30Z

By toggling the condition check for a valid buffer, the else path can be completely avoided. Signed-off-by: Michael Grzeschik Link: https://lore.kernel.org/r/20240214-uvc-gadget-cleanup-v1-2-de6d78780459@pengutronix.de Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: drop unnecessary check for always set req

2024-02-17T16:08:29Z

The pump function is running in an while(1) loop. The only case this loop will be escaped is the two breaks. In both cases the req is valid. Therefor the check for an not set req can be dropped and setting the req to NULL does also has never any effect. Signed-off-by: Michael Grzeschik Link: https://lore.kernel.org/r/20240214-uvc-gadget-cleanup-v1-1-de6d78780459@pengutronix.de Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: Remove nested locking

2024-01-05T09:35:57Z

When handling error status from uvcg_video_usb_req_queue, uvc_video_complete currently calls uvcg_queue_cancel with video->req_lock held. uvcg_queue_cancel internally locks queue->irqlock, which nests queue->irqlock inside video->req_lock. This isn't a functional bug at the moment, but does open up possibilities for ABBA deadlocks in the future. This patch fixes the accidental nesting by dropping video->req_lock before calling uvcg_queue_cancel. Fixes: 6acba0345b68 ("usb:gadget:uvc Do not use worker thread to pump isoc usb requests") Signed-off-by: Avichal Rakesh Link: https://lore.kernel.org/r/20240104215009.2252452-2-arakesh@google.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: Fix use are free during STREAMOFF

2024-01-05T09:35:57Z

There is a path that may lead to freed memory being referenced, causing kernel panics. The kernel panic has the following stack trace: Workqueue: uvcgadget uvcg_video_pump.c51fb85fece46625450f86adbf92c56c.cfi_jt pstate: 60c00085 (nZCv daIf +PAN +UAO -TCO BTYPE=--) pc : __list_del_entry_valid+0xc0/0xd4 lr : __list_del_entry_valid+0xc0/0xd4 Call trace: __list_del_entry_valid+0xc0/0xd4 uvc_video_free_request+0x60/0x98 uvcg_video_pump+0x1cc/0x204 process_one_work+0x21c/0x4b8 worker_thread+0x29c/0x574 kthread+0x158/0x1b0 ret_from_fork+0x10/0x30 The root cause is that uvcg_video_usb_req_queue frees the uvc_request if is_enabled is false and returns an error status. video_pump also frees the associated request if uvcg_video_usb_req_queue returns an error status, leading to double free and accessing garbage memory. To fix the issue, this patch removes freeing logic from uvcg_video_usb_req_queue, and lets the callers to the function handle queueing errors as they see fit. Fixes: 6acba0345b68 ("usb:gadget:uvc Do not use worker thread to pump isoc usb requests") Tested-by: Avichal Rakesh Signed-off-by: Avichal Rakesh Link: https://lore.kernel.org/r/20240104215009.2252452-1-arakesh@google.com Signed-off-by: Greg Kroah-Hartman

usb:gadget:uvc Do not use worker thread to pump isoc usb requests

2023-11-23T12:32:44Z

When we use an async work queue to perform the function of pumping usb requests to the usb controller, it is possible that amongst other factors, thread scheduling affects at what cadence we're able to pump requests. This could mean isoc usb requests miss their uframes - resulting in video stream flickers on the host device. To avoid this, we make the async_wq thread only produce isoc usb_requests with uvc buffers encoded into them. The process of queueing to the endpoint is done by the uvc_video_complete() handler. In case no usb_requests are ready with encoded information, we just queue a zero length request to the endpoint from the complete handler. For bulk endpoints the async_wq thread still queues usb requests to the endpoint. Signed-off-by: Michael Grzeschik Signed-off-by: Jayant Chowdhary Suggested-by: Avichal Rakesh Suggested-by: Alan Stern Link: https://lore.kernel.org/r/20231120062026.3759463-1-jchowdhary@google.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: Fix use-after-free for inflight usb_requests

2023-11-23T12:32:44Z

Currently, the uvc gadget driver allocates all uvc_requests as one array and deallocates them all when the video stream stops. This includes de-allocating all the usb_requests associated with those uvc_requests. This can lead to use-after-free issues if any of those de-allocated usb_requests were still owned by the usb controller. This is patch 2 of 2 in fixing the use-after-free issue. It adds a new flag to uvc_video to track when frames and requests should be flowing. When disabling the video stream, the flag is tripped and, instead of de-allocating all uvc_requests and usb_requests, the gadget driver only de-allocates those usb_requests that are currently owned by it (as present in req_free). Other usb_requests are left untouched until their completion handler is called which takes care of freeing the usb_request and its corresponding uvc_request. Now that uvc_video does not depends on uvc->state, this patch removes unnecessary upates to uvc->state that were made to accommodate uvc_video logic. This should ensure that uvc gadget driver never accidentally de-allocates a usb_request that it doesn't own. Link: https://lore.kernel.org/7cd81649-2795-45b6-8c10-b7df1055020d@google.com Reviewed-by: Daniel Scally Reviewed-by: Michael Grzeschik Suggested-by: Michael Grzeschik Tested-by: Michael Grzeschik Signed-off-by: Avichal Rakesh Link: https://lore.kernel.org/r/20231109004104.3467968-4-arakesh@google.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: move video disable logic to its own function

2023-11-23T12:32:44Z

This patch refactors the video disable logic in uvcg_video_enable into its own separate function 'uvcg_video_disable'. This function is now used anywhere uvcg_video_enable(video, 0) was used. Reviewed-by: Daniel Scally Suggested-by: Michael Grzeschik Signed-off-by: Avichal Rakesh Link: https://lore.kernel.org/r/20231109004104.3467968-3-arakesh@google.com Signed-off-by: Greg Kroah-Hartman