From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Ricardo Ribalda <ribalda@chromium.org>
Cc: Hans de Goede <hdegoede@redhat.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 2/2] media: uvcvideo: Remove dangling pointers
Date: Wed, 27 Nov 2024 11:35:06 +0200 [thread overview]
Message-ID: <20241127093506.GE31095@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20241127-uvc-fix-async-v1-2-eb8722531b8c@chromium.org>
Hi Ricardo,
Thank you for the patch.
On Wed, Nov 27, 2024 at 07:46:11AM +0000, Ricardo Ribalda wrote:
> When an async control is written, we copy a pointer to the file handle
> that started the operation. That pointer will be used when the device is
> done. Which could be anytime in the future.
>
> If the user closes that file descriptor, its structure will be freed,
> and there will be one dangling pointer per pending async control, that
> the driver will try to use.
>
> Clean all the dangling pointers during release().
>
> To avoid adding a performance penalty in the most common case (no async
> operation). A counter has been introduced with some logic to make sure
> that it is properly handled.
>
> Cc: stable@vger.kernel.org
> Fixes: e5225c820c05 ("media: uvcvideo: Send a control event when a Control Change interrupt arrives")
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
> drivers/media/usb/uvc/uvc_ctrl.c | 40 ++++++++++++++++++++++++++++++++++++++--
> drivers/media/usb/uvc/uvc_v4l2.c | 2 ++
> drivers/media/usb/uvc/uvcvideo.h | 3 +++
> 3 files changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
> index 5d3a28edf7f0..51a53ad25e9c 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -1589,7 +1589,12 @@ void uvc_ctrl_status_event(struct uvc_video_chain *chain,
> mutex_lock(&chain->ctrl_mutex);
>
> handle = ctrl->handle;
> - ctrl->handle = NULL;
> + if (handle) {
> + ctrl->handle = NULL;
> + WARN_ON(!handle->pending_async_ctrls);
> + if (handle->pending_async_ctrls)
> + handle->pending_async_ctrls--;
> + }
There's at least one other location where ctrl->handle is reset to NULL.
>
> list_for_each_entry(mapping, &ctrl->info.mappings, list) {
> s32 value = __uvc_ctrl_get_value(mapping, data);
> @@ -2050,8 +2055,11 @@ int uvc_ctrl_set(struct uvc_fh *handle,
> mapping->set(mapping, value,
> uvc_ctrl_data(ctrl, UVC_CTRL_DATA_CURRENT));
>
> - if (ctrl->info.flags & UVC_CTRL_FLAG_ASYNCHRONOUS)
> + if (ctrl->info.flags & UVC_CTRL_FLAG_ASYNCHRONOUS) {
> + if (!ctrl->handle)
> + handle->pending_async_ctrls++;
> ctrl->handle = handle;
Is this protected by ctrl_mutex ?
Please be careful about locking and race conditions, taking the time to
double check will help getting your patches merged faster.
> + }
>
> ctrl->dirty = 1;
> ctrl->modified = 1;
> @@ -2774,6 +2782,34 @@ int uvc_ctrl_init_device(struct uvc_device *dev)
> return 0;
> }
>
> +void uvc_ctrl_cleanup_fh(struct uvc_fh *handle)
> +{
> + struct uvc_entity *entity;
> +
> + guard(mutex)(&handle->chain->ctrl_mutex);
> +
> + if (!handle->pending_async_ctrls)
> + return;
> +
> + list_for_each_entry(entity, &handle->chain->dev->entities, list) {
> + int i;
unsigned int
I wonder if these days you could event write
for (unsigned int i = 0; i < entity->ncontrols; ++i) {
> +
> + for (i = 0; i < entity->ncontrols; ++i) {
> + struct uvc_control *ctrl = &entity->controls[i];
> +
> + if (!ctrl->handle || ctrl->handle != handle)
Given that handle can't be null, you can write
if (ctrl->handle != handle)
> + continue;
> +
> + ctrl->handle = NULL;
> + if (WARN_ON(!handle->pending_async_ctrls))
> + continue;
Is this needed ? If we find more controls for this handle than
pending_async_ctrls, decrementing it below 0 will case the WARN_ON() at
the end of this function to trigger, isn't that enough ?
> + handle->pending_async_ctrls--;
> + }
> + }
> +
> + WARN_ON(handle->pending_async_ctrls);
> +}
> +
> /*
> * Cleanup device controls.
> */
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
> index 97c5407f6603..b425306a3b8c 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -652,6 +652,8 @@ static int uvc_v4l2_release(struct file *file)
>
> uvc_dbg(stream->dev, CALLS, "%s\n", __func__);
>
> + uvc_ctrl_cleanup_fh(handle);
> +
> /* Only free resources if this is a privileged handle. */
> if (uvc_has_privileges(handle))
> uvc_queue_release(&stream->queue);
> diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
> index 07f9921d83f2..2f8a9c48e32a 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -612,6 +612,7 @@ struct uvc_fh {
> struct uvc_video_chain *chain;
> struct uvc_streaming *stream;
> enum uvc_handle_state state;
> + unsigned int pending_async_ctrls; /* Protected by ctrl_mutex. */
The kernel does it the other way around, it lists in the documentation
of the lock what data it protects.
> };
>
> struct uvc_driver {
> @@ -797,6 +798,8 @@ int uvc_ctrl_is_accessible(struct uvc_video_chain *chain, u32 v4l2_id,
> int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
> struct uvc_xu_control_query *xqry);
>
> +void uvc_ctrl_cleanup_fh(struct uvc_fh *handle);
> +
> /* Utility functions */
> struct usb_host_endpoint *uvc_find_endpoint(struct usb_host_interface *alts,
> u8 epaddr);
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2024-11-27 9:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-27 7:46 [PATCH 0/2] media: uvcvideo: Two fixes for async controls Ricardo Ribalda
2024-11-27 7:46 ` [PATCH 1/2] media: uvcvideo: Do not set an async control owned by other fh Ricardo Ribalda
2024-11-27 9:11 ` Laurent Pinchart
2024-11-27 9:25 ` Ricardo Ribalda
2024-11-27 9:42 ` Laurent Pinchart
2024-11-27 10:19 ` Ricardo Ribalda
2024-11-27 7:46 ` [PATCH 2/2] media: uvcvideo: Remove dangling pointers Ricardo Ribalda
2024-11-27 9:35 ` Laurent Pinchart [this message]
2024-11-27 10:23 ` Ricardo Ribalda
2024-11-28 20:51 ` Laurent Pinchart
2024-11-28 20:56 ` Ricardo Ribalda
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=20241127093506.GE31095@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=guennadi.liakhovetski@intel.com \
--cc=hdegoede@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab+samsung@kernel.org \
--cc=mchehab@kernel.org \
--cc=ribalda@chromium.org \
--cc=stable@vger.kernel.org \
/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.