Thank you for testing the patch, Michael! On 10/3/23 04:09, Michael Grzeschik wrote: > Hi > > On Sat, Sep 30, 2023 at 11:48:18AM -0700, Avichal Rakesh wrote: >> We have been seeing two main stability issues that uvc gadget driver >> runs into when stopping streams: >> 1. Attempting to queue usb_requests to a disabled usb_ep >> 2. use-after-free issue for inflight usb_requests >> >> The three patches below fix the two issues above. Patch 1/3 fixes the >> first issue, and Patch 2/3 and 3/3 fix the second issue. >> >> Avichal Rakesh (3): >> usb: gadget: uvc: prevent use of disabled endpoint >> usb: gadget: uvc: Allocate uvc_requests one at a time >> usb: gadget: uvc: Fix use-after-free for inflight usb_requests >> >> drivers/usb/gadget/function/f_uvc.c | 11 +- >> drivers/usb/gadget/function/f_uvc.h | 2 +- >> drivers/usb/gadget/function/uvc.h | 6 +- >> drivers/usb/gadget/function/uvc_v4l2.c | 21 ++- >> drivers/usb/gadget/function/uvc_video.c | 189 +++++++++++++++++------- >> 5 files changed, 164 insertions(+), 65 deletions(-) > > These patches are not applying on gregkh/usb-testing since > Greg did take my patches first. I have already rebased them. Ah, I didn't realize Greg had picked up your changes in his tree. Rebased the patches in V2. Also want to point out that https://lore.kernel.org/20230911002451.2860049-2-m.grzeschik@xxxxxxxxxxxxxx/ may have introduced an issue when setting the uvc->state to UVC_STATE_CONNECTED in uvcg_video_enable. Effectively, uvc_video_enable can be called 1. because the host asks to halt the stream, or 2. if the gadget was disabled. Setting uvc->state to CONNECTED is fine for (1). In (2), uvc_v4l2 sets uvc->state to DISCONNECTED before calling uvcg_video_enable. In this case, your change would overwrite the value to CONNECTED without any further checks. > > In the updated version I the stack runs into the > following error, when enabling lockdep. Could you > try your version with lockdep enabled? > > [ 41.278520] configfs-gadget.vz gadget.0: uvc: reset UVC > [ 47.156261] configfs-gadget.vz gadget.0: uvc: uvc_function_set_alt(2, 0) > [ 47.169177] > [ 47.170903] ============================================ > [ 47.176857] WARNING: possible recursive locking detected > [ 47.182798] 6.5.0-20230919-1+ #19 Tainted: G C > [ 47.189323] -------------------------------------------- > [ 47.195256] vzuvcd/412 is trying to acquire lock: > [ 47.200511] ffffff8009560928 (&video->req_lock){....}-{3:3}, at: uvc_video_complete+0x44/0x2e0 > [ 47.210172] > [ 47.210172] but task is already holding lock: > [ 47.216687] ffffff8009560928 (&video->req_lock){....}-{3:3}, at: uvcg_video_enable+0x2d0/0x5c0 > [ 47.226333] > [ 47.226333] other info that might help us debug this: > [ 47.233625] Possible unsafe locking scenario: > [ 47.233625] > [ 47.240242] CPU0 > [ 47.242974] ---- > [ 47.245709] lock(&video->req_lock); > [ 47.249802] lock(&video->req_lock); > [ 47.253897] > [ 47.253897] *** DEADLOCK *** > [ 47.253897] > [ 47.260511] May be due to missing lock nesting notation > [ 47.260511] > Thank you for catching this. I couldn't repro the deadlock, but it looks like DWC3 controller can call the complete callback directly from usb_ep_dequeue for requests in its pending list. I am not sure if that is up to spec, considering calling usb_ep_queue explicitly forbids calling the complete callback from within. Regardless, it is easy enough to fix by moving the dequeue calls to before we acquire req_lock. The semantics of the rest of the patch is unchanged. Uploading the fixed patches shortly. Regards, Avi.
