On Tue, Oct 03, 2023 at 01:09:06PM +0200, Michael Grzeschik wrote:
> 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.
I think they got merged too soon :-( We could fix things on top, but
there's very little time to do so for v6.7.
> 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]
--
Regards,
Laurent Pinchart
