Re: [syzbot] [usb?] [media?] possible deadlock in vb2_video_unregister_device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 20, 2024 at 12:49 AM Benjamin Gaignard
<benjamin.gaignard@xxxxxxxxxxxxx> wrote:
>
>
> Le 19/02/2024 à 14:10, syzbot a écrit :
> > syzbot has bisected this issue to:
> >
> > commit c838530d230bc638d79b78737fc4488ffc28c1ee
> > Author: Benjamin Gaignard <benjamin.gaignard@xxxxxxxxxxxxx>
> > Date:   Thu Nov 9 16:34:59 2023 +0000
> >
> >      media: media videobuf2: Be more flexible on the number of queue stored buffers
> >
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000
> > start commit:   b401b621758e Linux 6.8-rc5
> > git tree:       upstream
> > final oops:     https://syzkaller.appspot.com/x/report.txt?x=156dc872180000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=116dc872180000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=eff9f3183d0a20dd
> > dashboard link: https://syzkaller.appspot.com/bug?extid=3b1d4b3d5f7a358bf9a9
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13ffaae8180000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13ef909c180000
> >
> > Reported-by: syzbot+3b1d4b3d5f7a358bf9a9@xxxxxxxxxxxxxxxxxxxxxxxxx
> > Fixes: c838530d230b ("media: media videobuf2: Be more flexible on the number of queue stored buffers")
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> Hans,
> I think the issue occur because of this part of the commit:
> @@ -1264,7 +1264,7 @@ void vb2_video_unregister_device(struct video_device *vdev)
>           */
>          get_device(&vdev->dev);
>          video_unregister_device(vdev);
> -       if (vdev->queue && vdev->queue->owner) {
> +       if (vdev->queue) {
>                  struct mutex *lock = vdev->queue->lock ?
>                          vdev->queue->lock : vdev->lock;
>
> but I wonder if the correction shouldn't be to remove usbtv->vb2q_lock mutex in usbtv_video_free().
>
> Any opinion ?

That is probably what triggered the failure detected by syzbot, but I
don't think we've ever had a guarantee that owner is NULL in that
code.

Looking at the uvc driver [1], it doesn't seem to need any special
locking there (after all the vb2 code acquires them).  (It also
doesn't have the custom clean-up code that the usbtv driver has in
usbtv_stop(), but that's another story). So maybe all we need to fix
it is removing the mutex_lock/unlock() calls?

[1] https://elixir.bootlin.com/linux/v6.8-rc4/source/drivers/media/usb/uvc/uvc_driver.c#L1906

Best,
Tomasz





[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux