From: sashiko-bot@kernel.org
To: "Rohith Matam" <rohithmatham@gmail.com>
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH v3] media: siano: fix URB work teardown
Date: Mon, 01 Jun 2026 15:36:51 +0000 [thread overview]
Message-ID: <20260601153652.0D4EB1F00899@smtp.kernel.org> (raw)
In-Reply-To: <20260601152642.55313-1-rohithmatham@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Potential deadlock during device teardown due to unkillable wait in smscore_getbuffer().
--
commit 253a5b71eec477524dcacfed05b5e2e64ea4ebbe
Author: Rohith Matam <rohithmatham@gmail.com>
media: siano: fix URB work teardown
This commit reinitializes URB work items before scheduling to prevent workqueue
warnings during teardown races. It also removes URB_FREE_BUFFER to fix buffer
lifetime issues and adjusts buffer management wakeups.
Closes: https://syzkaller.appspot.com/bug?extid=0d6ef2b7ceb6014d756c
> diff --git a/drivers/media/usb/siano/smsusb.c b/drivers/media/usb/siano/smsusb.c
> index 0fdc2e0950b77..fab64e5fa6804 100644
> --- a/drivers/media/usb/siano/smsusb.c
> +++ b/drivers/media/usb/siano/smsusb.c
[ ... ]
> @@ -183,12 +192,15 @@ static void smsusb_stop_streaming(struct smsusb_device_t *dev)
> {
> int i;
>
> + WRITE_ONCE(dev->streaming, false);
> +
> for (i = 0; i < MAX_URBS; i++) {
> usb_kill_urb(dev->surbs[i].urb);
> - if (dev->surbs[i].wq.func)
> - cancel_work_sync(&dev->surbs[i].wq);
> + cancel_work_sync(&dev->surbs[i].wq);
[Severity: High]
This is a pre-existing issue, but can this sequence cause a deadlock during
teardown?
When smsusb_stop_streaming is called, it iterates over the URBs and calls
cancel_work_sync sequentially. If a worker thread executing do_submit_urb is
concurrently blocked inside smscore_getbuffer waiting for a buffer, it waits
in TASK_UNINTERRUPTIBLE without an abort condition:
drivers/media/common/siano/smscoreapi.c:smscore_getbuffer() {
struct smscore_buffer_t *cb = NULL;
wait_event(coredev->buffer_mng_waitq, (cb = get_entry(coredev)));
return cb;
}
Because cancel_work_sync is waiting for this worker to finish, the teardown
loop halts and cannot proceed to subsequent URBs to release their buffers
back to the pool via smscore_putbuffer.
Since no more buffers will be returned during teardown, does the worker
sleep forever, causing cancel_work_sync to hang indefinitely?
> + usb_kill_urb(dev->surbs[i].urb);
>
> if (dev->surbs[i].cb) {
> smscore_putbuffer(dev->coredev, dev->surbs[i].cb);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260601152642.55313-1-rohithmatham@gmail.com?part=1
next prev parent reply other threads:[~2026-06-01 15:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 6:18 [PATCH] media: usb: siano: initialize URB work once Rohith Matam
2026-06-01 6:34 ` sashiko-bot
2026-06-01 15:09 ` [PATCH v2] media: usb: siano: fix URB work teardown Rohith Matam
2026-06-01 15:21 ` sashiko-bot
2026-06-01 15:26 ` [PATCH v3] media: " Rohith Matam
2026-06-01 15:36 ` sashiko-bot [this message]
2026-06-01 15:43 ` [PATCH v4] " Rohith Matam
2026-06-01 15:55 ` sashiko-bot
2026-06-01 16:04 ` [PATCH v5] " Rohith Matam
2026-06-01 16:15 ` sashiko-bot
2026-06-01 20:16 ` [PATCH v6] " Rohith Matam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260601153652.0D4EB1F00899@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=rohithmatham@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.