All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@linaro.org>
To: Pavan Kumar Yalagada <pavankumaryalagada@gmail.com>
Cc: parthiban.veerasooran@microchip.com,
	christian.gromm@microchip.com, gregkh@linuxfoundation.org,
	laurent.pinchart+renesas@ideasonboard.com,
	hverkuil+cisco@kernel.org, linux-staging@lists.linux.dev
Subject: Re: [PATCH v3] staging: most: video: prevent probes during component exit
Date: Sat, 29 Nov 2025 15:06:23 +0300	[thread overview]
Message-ID: <aSrhv46__garLySK@stanley.mountain> (raw)
In-Reply-To: <20251128165033.25060-1-pavankumaryalagada@gmail.com>

On Fri, Nov 28, 2025 at 11:50:33AM -0500, Pavan Kumar Yalagada wrote:
> When comp_exit() runs, comp_probe_channel() could still add new devices
> to video_devices, creating a race and potentially leaving the list in
> an inconsistent state.
> 
> This patch prevents new devices from being added while exiting by:
> 
>  - comp_exiting is set under lock to prevent new devices being added.
>  - Early exit paths free allocated memory (kfree) to avoid leaks.
>  - comp_probe_channel() checks comp_exiting before modifying video_devices.
>  - Removing WARN/BUG as it becomes unnecessary.
> 
> Signed-off-by: Pavan Kumar Yalagada <pavankumaryalagada@gmail.com>
> 
> ---
> 
> v3:
>  - comp_exiting flag update and memory cleanup for early exits.
>  - Commit message clarified for reviewers.
> ---
>  drivers/staging/most/video/video.c | 19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/most/video/video.c b/drivers/staging/most/video/video.c
> index 32f71d9a9cf7..f257fb179813 100644
> --- a/drivers/staging/most/video/video.c
> +++ b/drivers/staging/most/video/video.c
> @@ -60,6 +60,8 @@ static inline struct comp_fh *to_comp_fh(struct file *filp)
>  static LIST_HEAD(video_devices);
>  static DEFINE_SPINLOCK(list_lock);
> 
> +static bool comp_exiting;
> +
>  static inline bool data_ready(struct most_video_dev *mdev)
>  {
>  	return !list_empty(&mdev->pending_mbos);
> @@ -498,13 +500,22 @@ static int comp_probe_channel(struct most_interface *iface, int channel_idx,
>  		goto err_unreg;
> 
>  	spin_lock_irq(&list_lock);
> +	if (comp_exiting) {
> +		spin_unlock_irq(&list_lock);
> +		goto err_cleanup;

Why do you not need to unregister?  I don't think this error handling
is correct.

> +	}
>  	list_add(&mdev->list, &video_devices);
>  	spin_unlock_irq(&list_lock);
>  	return 0;
> 
> +err_cleanup:
> +	kfree(mdev);
> +	return -EBUSY;
> +
>  err_unreg:
>  	v4l2_device_disconnect(&mdev->v4l2_dev);
>  	v4l2_device_put(&mdev->v4l2_dev);
> +	kfree(mdev);
>  	return ret;
>  }
> 
> @@ -553,8 +564,13 @@ static int __init comp_init(void)
> 
>  static void __exit comp_exit(void)
>  {
> +	unsigned long flags;
>  	struct most_video_dev *mdev, *tmp;
> 
> +	spin_lock_irqsave(&list_lock, flags);
> +	comp_exiting = true;
> +	spin_unlock_irqrestore(&list_lock, flags);
> +

It doesn't make sense to call spin_unlock_irqrestore()
and the spin_lock_irq() on the next line.

So the issue is, we want a write barrier so that the write in comp_exit()
happens before the read in comp_probe_channel(), which the spinlocks
do accomplish, I suppose.

>  	/*
>  	 * As the mostcore currently doesn't call disconnect_channel()
>  	 * for linked channels while we call most_deregister_component()
> @@ -569,13 +585,14 @@ static void __exit comp_exit(void)
>  		comp_unregister_videodev(mdev);
>  		v4l2_device_disconnect(&mdev->v4l2_dev);
>  		v4l2_device_put(&mdev->v4l2_dev);
> +		kfree(mdev);

No no.  This isn't related to race conditions and it's probably
wrong as well.

regards,
dan carpenter


      reply	other threads:[~2025-11-29 12:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-28 16:50 [PATCH v3] staging: most: video: prevent probes during component exit Pavan Kumar Yalagada
2025-11-29 12:06 ` Dan Carpenter [this message]

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=aSrhv46__garLySK@stanley.mountain \
    --to=dan.carpenter@linaro.org \
    --cc=christian.gromm@microchip.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hverkuil+cisco@kernel.org \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-staging@lists.linux.dev \
    --cc=parthiban.veerasooran@microchip.com \
    --cc=pavankumaryalagada@gmail.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 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.