lkml.org 
[lkml]   [2023]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v1 0/3] usb: gadget: uvc: stability fixes on STREAMOFF.
    From
    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@pengutronix.de/
    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.

    \
     
     \ /
      Last update: 2023-10-04 01:17    [W:4.082 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site