mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: hverkuil+cisco@kernel.org
To: Fan Wu <fanwu01@zju.edu.cn>, mchehab@kernel.org
Cc: y-abhilashchandra@ti.com, bparrot@ti.com, dale@farnsworth.org,
	dagriego@biglakesoftware.com, sbellary@baylibre.com,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v4] media: ti: vpe: quiesce overflow recovery before freeing streams
Date: Tue, 28 Jul 2026 13:06:58 +0200	[thread overview]
Message-ID: <bf618e7c-6b18-4015-aa4d-9d08c86d5577@kernel.org> (raw)
In-Reply-To: <20260716113230.3131086-1-fanwu01@zju.edu.cn>

On 16/07/2026 13:32, Fan Wu wrote:
> The VIP overflow recovery worker is armed from the hardirq handler when a
> FIFO overflow is detected, and the list-complete path looks the stream up
> through the VPDMA list private pointer. Both keep touching stream, port
> and device state; the recovery worker also resets the parser and VPDMA,
> repopulates the descriptor list, and re-enables the per-list IRQs.
> 
> vip_stop_streaming() masks and clears the per-list IRQs, but it neither
> synchronizes the hardirq handler nor disables recovery_work. An overflow
> IRQ that has already queued recovery_work, or a list-complete IRQ in
> flight when the stream is torn down, can therefore still dereference the
> stream after its resources are released: the descriptor list is freed by
> vip_release_stream() on file release, and the stream itself by
> free_stream() on unbind/remove.
> 
> Drain the recovery worker and the IRQ handler at both teardown points
> through a shared vip_quiesce_stream() helper, before any stream-owned
> resource is released. disable_work_sync() cancels pending recovery_work,
> drains a running instance, and raises its disable depth, so a subsequent
> schedule_work() issued by a racing IRQ handler is rejected at the
> workqueue scheduler: recovery_work cannot be requeued after
> disable_work_sync() takes effect. The worker may still re-enable the
> per-list IRQs before disable_work_sync() returns; disable_irqs() then
> masks those sources and synchronize_irq() waits for any in-flight handler
> that still dereferences stream state. In vip_stop_streaming() the helper
> runs before the parser is stopped, since a worker drained by
> disable_work_sync() may re-enable the parser before exiting and would
> otherwise undo the stop. recovery_work is created disabled and enabled in
> vip_start_streaming() before IRQs, pairing the enable with the teardown
> disable across the streaming lifecycle.
> 
> This issue was found by an in-house static analysis tool and confirmed
> by manual code review.
> 
> Fixes: fc2873aa4a21 ("media: ti: vpe: Add the VIP driver")
> Cc: stable@vger.kernel.org
> Assisted-by: Codex:gpt-5.6
> Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
> ---
> Changes in v4:
> - Drop the unrelated vpdma_hwlist_release() cleanup from this fix (Hans
>   Verkuil).
> - In free_stream(), call vip_quiesce_stream() before clearing
>   cap_streams[], so the stream remains published while in-flight IRQ
>   handling is drained (Hans Verkuil).

Ah, I already merged v3, so v4 doesn't apply.

Can you post a new patch that sits on top of the current media-committers/next
tree?

Thank you,

	Hans

> 
> Changes in v3:
> - Replace the per-stream irq_rearm_allowed flag and the repeated IRQ
>   disable/synchronize_irq() in vip_quiesce_stream() with the workqueue
>   disable-depth API (disable_work_sync/enable_work/disable_work), as
>   suggested by Yemike Abhilash Chandra. This also closes a window the v2
>   double-drain left open, where its second synchronize_irq() waited for
>   the in-flight handler but did not cancel the recovery_work it had
>   requeued, so that work could run after free.
> - Create recovery_work disabled and enable it in vip_start_streaming()
>   before IRQs.
> - In vip_stop_streaming(), quiesce before stopping the parser: a worker
>   drained by disable_work_sync() may re-enable the parser before exiting,
>   so stopping the parser first would be undone.
> 
> Changes in v2:
> - Drain the overflow recovery worker at both teardown points through a
>   shared vip_quiesce_stream() helper: vip_stop_streaming() (file release
>   path) and free_stream() (unbind/remove). v1 drained only in
>   free_stream().
> - Document how the issue was found and that the patch was prepared with
>   LLM assistance (Assisted-by trailer and body note).
> 
> Link: https://lore.kernel.org/r/20260708013738.110752-1-fanwu01@zju.edu.cn/
> ---
>  drivers/media/platform/ti/vpe/vip.c | 37 +++++++++++++++++++++++++----
>  1 file changed, 33 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/ti/vpe/vip.c b/drivers/media/platform/ti/vpe/vip.c
> index cb0a5a07a3d4..673f9addfade 100644
> --- a/drivers/media/platform/ti/vpe/vip.c
> +++ b/drivers/media/platform/ti/vpe/vip.c
> @@ -814,6 +814,22 @@ static void clear_irqs(struct vip_dev *dev, int irq_num, int list_num)
>  	vpdma_clear_list_stat(dev->shared->vpdma, irq_num, dev->slice_id);
>  }
>  
> +/*
> + * Quiesce recovery work and per-list IRQs before releasing stream resources.
> + * disable_work_sync() prevents the overflow handler from requeueing recovery
> + * work. Mask and synchronize IRQs afterwards because a running worker may
> + * have re-enabled them before exiting.
> + */
> +static void vip_quiesce_stream(struct vip_stream *stream)
> +{
> +	struct vip_dev *dev = stream->port->dev;
> +
> +	disable_work_sync(&stream->recovery_work);
> +	disable_irqs(dev, dev->slice_id, stream->list_num);
> +	clear_irqs(dev, dev->slice_id, stream->list_num);
> +	synchronize_irq(dev->irq);
> +}
> +
>  static void populate_desc_list(struct vip_stream *stream)
>  {
>  	struct vip_port *port = stream->port;
> @@ -2428,6 +2444,7 @@ static int vip_start_streaming(struct vb2_queue *vq, unsigned int count)
>  		goto err;
>  
>  	stream->num_recovery = 0;
> +	enable_work(&stream->recovery_work);
>  
>  	clear_irqs(dev, dev->slice_id, stream->list_num);
>  	enable_irqs(dev, dev->slice_id, stream->list_num);
> @@ -2452,13 +2469,17 @@ static void vip_stop_streaming(struct vb2_queue *vq)
>  	struct vip_dev *dev = port->dev;
>  	int ret;
>  
> +	/*
> +	 * A running recovery worker may re-enable the parser, so quiesce it
> +	 * and its IRQ handler before stopping the parser or releasing the
> +	 * descriptor list.
> +	 */
> +	vip_quiesce_stream(stream);
> +
>  	vip_parser_stop_imm(port, true);
>  	vip_enable_parser(port, false);
>  	unset_fmt_params(stream);
>  
> -	disable_irqs(dev, dev->slice_id, stream->list_num);
> -	clear_irqs(dev, dev->slice_id, stream->list_num);
> -
>  	if (port->subdev) {
>  		ret = v4l2_subdev_call(port->subdev, video, s_stream, 0);
>  		if (ret)
> @@ -3074,6 +3095,8 @@ static int alloc_stream(struct vip_port *port, int stream_id, int vfl_type)
>  		goto do_free_hwlist;
>  
>  	INIT_WORK(&stream->recovery_work, vip_overflow_recovery_work);
> +	/* Start disabled; vip_start_streaming() enables it before IRQs. */
> +	disable_work(&stream->recovery_work);
>  
>  	INIT_LIST_HEAD(&stream->vidq);
>  
> @@ -3139,6 +3162,13 @@ static void free_stream(struct vip_stream *stream)
>  		return;
>  
>  	dev = stream->port->dev;
> +	/*
> +	 * Quiesce the IRQ handler and recovery worker, then drop the stream
> +	 * from cap_streams[], before releasing stream-owned resources.
> +	 */
> +	vip_quiesce_stream(stream);
> +	stream->port->cap_streams[stream->stream_id] = NULL;
> +
>  	/* Free up the Drop queue */
>  	list_for_each_safe(pos, q, &stream->dropq) {
>  		buf = list_entry(pos,
> @@ -3150,7 +3180,6 @@ static void free_stream(struct vip_stream *stream)
>  
>  	video_unregister_device(stream->vfd);
>  	vpdma_hwlist_release(dev->shared->vpdma, stream->list_num);
> -	stream->port->cap_streams[stream->stream_id] = NULL;
>  	kfree(stream);
>  }
>  


  parent reply	other threads:[~2026-07-28 11:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-07  1:52 [PATCH] " Fan Wu
2026-07-07  8:54 ` Yemike Abhilash Chandra
2026-07-07 11:49   ` Fan Wu
2026-07-08  1:37   ` [PATCH v2] " Fan Wu
2026-07-08  1:40   ` [PATCH] " Fan Wu
2026-07-12 17:09     ` Yemike Abhilash Chandra
2026-07-13 19:56   ` [PATCH v3] " Fan Wu
2026-07-15 12:55     ` hverkuil+cisco
2026-07-16 11:32       ` [PATCH v4] " Fan Wu
2026-07-24  8:29         ` Yemike Abhilash Chandra
2026-07-28 11:06         ` hverkuil+cisco [this message]
2026-07-28 11:39           ` Hans Verkuil
2026-07-21  6:15       ` [PATCH v3] " Yemike Abhilash Chandra

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=bf618e7c-6b18-4015-aa4d-9d08c86d5577@kernel.org \
    --to=hverkuil+cisco@kernel.org \
    --cc=bparrot@ti.com \
    --cc=dagriego@biglakesoftware.com \
    --cc=dale@farnsworth.org \
    --cc=fanwu01@zju.edu.cn \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=sbellary@baylibre.com \
    --cc=stable@vger.kernel.org \
    --cc=y-abhilashchandra@ti.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®