Linux Media Controller development
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: linux-media@vger.kernel.org, laurent.pinchart@ideasonboard.com
Subject: Re: [PATCH v2 17/29] media: v4l: Acquire a reference to the media device for every video device
Date: Tue, 5 Mar 2024 07:43:32 +0000	[thread overview]
Message-ID: <ZebNJK7TMcBJVLv6@kekkonen.localdomain> (raw)
In-Reply-To: <ZdXiOxOxKi6U6Ayn@kekkonen.localdomain>

Hi Hans,

On Wed, Feb 21, 2024 at 11:44:59AM +0000, Sakari Ailus wrote:
> Hi Hans,
> 
> On Wed, Feb 21, 2024 at 11:51:08AM +0100, Hans Verkuil wrote:
> > On 21/02/2024 11:40, Sakari Ailus wrote:
> > > Hi Hans,
> > > 
> > > Many thanks for reviewing these.
> > > 
> > > On Mon, Feb 05, 2024 at 03:56:22PM +0100, Hans Verkuil wrote:
> > >> On 20/12/2023 11:37, Sakari Ailus wrote:
> > >>> The video device depends on the existence of its media device --- if there
> > >>> is one. Acquire a reference to it.
> > >>>
> > >>> Note that when the media device release callback is used, then the V4L2
> > >>> device release callback is ignored and a warning is issued if both are
> > >>> set.
> > >>>
> > >>> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > >>> ---
> > >>>  drivers/media/v4l2-core/v4l2-dev.c | 51 ++++++++++++++++++++----------
> > >>>  1 file changed, 34 insertions(+), 17 deletions(-)
> > >>>
> > >>> diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c
> > >>> index d13954bd31fd..c1e4995eaf5c 100644
> > >>> --- a/drivers/media/v4l2-core/v4l2-dev.c
> > >>> +++ b/drivers/media/v4l2-core/v4l2-dev.c
> > >>> @@ -176,6 +176,11 @@ static void v4l2_device_release(struct device *cd)
> > >>>  {
> > >>>  	struct video_device *vdev = to_video_device(cd);
> > >>>  	struct v4l2_device *v4l2_dev = vdev->v4l2_dev;
> > >>> +	bool v4l2_dev_has_release = v4l2_dev->release;
> > >>> +#ifdef CONFIG_MEDIA_CONTROLLER
> > >>> +	struct media_device *mdev = v4l2_dev->mdev;
> > >>> +	bool mdev_has_release = mdev && mdev->ops && mdev->ops->release;
> > >>> +#endif
> > >>>  
> > >>>  	mutex_lock(&videodev_lock);
> > >>>  	if (WARN_ON(video_devices[vdev->minor] != vdev)) {
> > >>> @@ -198,8 +203,8 @@ static void v4l2_device_release(struct device *cd)
> > >>>  
> > >>>  	mutex_unlock(&videodev_lock);
> > >>>  
> > >>> -#if defined(CONFIG_MEDIA_CONTROLLER)
> > >>> -	if (v4l2_dev->mdev && vdev->vfl_dir != VFL_DIR_M2M) {
> > >>> +#ifdef CONFIG_MEDIA_CONTROLLER
> > >>> +	if (mdev && vdev->vfl_dir != VFL_DIR_M2M) {
> > >>>  		/* Remove interfaces and interface links */
> > >>>  		media_devnode_remove(vdev->intf_devnode);
> > >>>  		if (vdev->entity.function != MEDIA_ENT_F_UNKNOWN)
> > >>> @@ -207,23 +212,31 @@ static void v4l2_device_release(struct device *cd)
> > >>>  	}
> > >>>  #endif
> > >>>  
> > >>> -	/* Do not call v4l2_device_put if there is no release callback set.
> > >>> -	 * Drivers that have no v4l2_device release callback might free the
> > >>> -	 * v4l2_dev instance in the video_device release callback below, so we
> > >>> -	 * must perform this check here.
> > >>> -	 *
> > >>> -	 * TODO: In the long run all drivers that use v4l2_device should use the
> > >>> -	 * v4l2_device release callback. This check will then be unnecessary.
> > >>> -	 */
> > >>> -	if (v4l2_dev->release == NULL)
> > >>> -		v4l2_dev = NULL;
> > >>> -
> > >>>  	/* Release video_device and perform other
> > >>>  	   cleanups as needed. */
> > >>>  	vdev->release(vdev);
> > >>>  
> > >>> -	/* Decrease v4l2_device refcount */
> > >>> -	if (v4l2_dev)
> > >>> +#ifdef CONFIG_MEDIA_CONTROLLER
> > >>> +	if (mdev)
> > >>> +		media_device_put(mdev);
> > >>> +
> > >>> +	/*
> > >>> +	 * Generally both struct media_device and struct v4l2_device are
> > >>> +	 * embedded in the same driver's context struct so having a release
> > >>> +	 * callback in both is a bug.
> > >>> +	 */
> > >>> +	WARN_ON(v4l2_dev_has_release && mdev_has_release);
> > >>
> > >> How about:
> > >>
> > >> 	if (WARN_ON(v4l2_dev_has_release && mdev_has_release))
> > >> 		v4l2_dev_has_release = false;
> > >>
> > >>> +#endif
> > >>> +
> > >>> +	/*
> > >>> +	 * Decrease v4l2_device refcount, but only if the media device doesn't
> > >>> +	 * have a release callback.
> > >>> +	 */
> > >>> +	if (v4l2_dev_has_release
> > >>> +#ifdef CONFIG_MEDIA_CONTROLLER
> > >>> +	    && !mdev_has_release
> > >>> +#endif
> > >>> +	    )
> > >>
> > >> Then this change is no longer needed.
> > > 
> > > Good idea.
> > > 
> > > I'll also rename v4l2_dev_has_release as v4l2_dev_call_release.
> > > 
> > >>
> > >> General question: do we have drivers today that set both release functions?
> > >> Because that would now cause a WARN in the kernel log with this patch.
> > > 
> > > Indeed, the intention is to be vocal about it.
> > > 
> > > The only user of the v4l2_device release function I could find is
> > > drivers/media/radio/dsbr100.c . I may have missed some but it certainly
> > > isn't commonly used. Maybe we could try to drop refcounting from
> > > v4l2_device later on?
> > 
> > There are a lot more drivers that use this. A quick grep shows gspca, hackrf,
> > usbtv, pwc, au0828 and more.
> > 
> > git grep v4l2_dev.*release.*= drivers/media/
> > 
> > Currently it is the only way to properly release drivers that create multiple
> > video (or other) devices.
> 
> I mistakenly grepped for ->release, .release is actually more common. I'll
> check how this is currently being used.

Getting back to the topic---indeed the V4L2 device release function is used
by a number of drivers today. Moving to the Media device release function
is no small task: I checked some drivers and while releasing the resources
is centralised in this case, unregistering the interfaces and releasing
actual resources may be intertwined so that fixing this requires reworking
much of the driver code. It's better to leave this for driver authors or at
least someone who has the hardware.

-- 
Sakari Ailus

  reply	other threads:[~2024-03-05  7:43 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-20 10:36 [PATCH v2 00/29] Media device lifetime management Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 01/29] Revert "[media] media: fix media devnode ioctl/syscall and unregister race" Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 02/29] Revert "media: utilize new cdev_device_add helper function" Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 03/29] Revert "[media] media: fix use-after-free in cdev_put() when app exits after driver unbind" Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 04/29] media: mc: utilize new cdev_device_add helper function Sakari Ailus
2024-02-07  9:38   ` Laurent Pinchart
2024-02-07  9:51     ` Laurent Pinchart
2024-02-21 12:55       ` Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 05/29] Revert "media: uvcvideo: Refactor teardown of uvc on USB disconnect" Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 06/29] Revert "[media] media-device: dynamically allocate struct media_devnode" Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 07/29] media: uvcvideo: Refactor teardown of uvc on USB disconnect Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 08/29] media: mc: Drop nop release callback Sakari Ailus
2024-02-07  9:55   ` Laurent Pinchart
2023-12-20 10:36 ` [PATCH v2 09/29] media: mc: Do not call cdev_device_del() if cdev_device_add() fails Sakari Ailus
2024-02-07  9:57   ` Laurent Pinchart
2024-03-05  8:13     ` Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 10/29] media: mc: Delete character device early Sakari Ailus
2024-02-07 10:08   ` Laurent Pinchart
2024-03-05  8:52     ` Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 11/29] media: mc: Split initialising and adding media devnode Sakari Ailus
2024-02-07 10:46   ` Laurent Pinchart
2024-03-05  8:59     ` Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 12/29] media: mc: Shuffle functions around Sakari Ailus
2024-02-07 10:47   ` Laurent Pinchart
2023-12-20 10:36 ` [PATCH v2 13/29] media: mc: Initialise media devnode in media_device_init() Sakari Ailus
2024-02-07 10:51   ` Laurent Pinchart
2023-12-20 10:36 ` [PATCH v2 14/29] media: mc: Refactor media devnode minor clearing Sakari Ailus
2024-02-05 14:46   ` Hans Verkuil
2024-02-07 10:53   ` Laurent Pinchart
2023-12-20 10:36 ` [PATCH v2 15/29] media: mc: Unassign minor only if it has been assigned Sakari Ailus
2024-02-05 14:48   ` Hans Verkuil
2024-02-07 10:58   ` Laurent Pinchart
2024-02-21  9:24     ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 16/29] media: mc: Refcount the media device Sakari Ailus
2024-02-07 11:08   ` Laurent Pinchart
2024-03-07 10:37     ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 17/29] media: v4l: Acquire a reference to the media device for every video device Sakari Ailus
2024-02-05 14:56   ` Hans Verkuil
2024-02-07 11:13     ` Laurent Pinchart
2024-02-21 10:43       ` Sakari Ailus
2024-02-21 12:19         ` Laurent Pinchart
2024-02-21 12:35           ` Sakari Ailus
2024-02-21 10:40     ` Sakari Ailus
2024-02-21 10:51       ` Hans Verkuil
2024-02-21 11:44         ` Sakari Ailus
2024-03-05  7:43           ` Sakari Ailus [this message]
2024-03-05  7:46             ` Hans Verkuil
2023-12-20 10:37 ` [PATCH v2 18/29] media: mc: Postpone graph object removal until free Sakari Ailus
2024-02-07 14:18   ` Laurent Pinchart
2024-06-04 10:59     ` Sakari Ailus
2024-06-04 11:01       ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 19/29] media: omap3isp: Release the isp device struct by media device callback Sakari Ailus
2024-02-07 14:23   ` Laurent Pinchart
2024-06-05  9:23     ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 20/29] media: ipu3-cio2: Call v4l2_device_unregister() earlier Sakari Ailus
2024-02-07 14:24   ` Laurent Pinchart
2024-03-05 10:21     ` Sakari Ailus
2024-03-05 10:22       ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 21/29] media: ipu3-cio2: Request IRQ earlier Sakari Ailus
2024-02-05 14:58   ` Hans Verkuil
2024-02-07 14:34     ` Laurent Pinchart
2024-02-21 10:51       ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 22/29] media: ipu3-cio2: Release the cio2 device context by media device callback Sakari Ailus
2024-02-07 14:33   ` Laurent Pinchart
2024-03-07 12:23     ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 23/29] media: vimc: Release resources on media device release Sakari Ailus
2024-02-05 15:02   ` Hans Verkuil
2024-02-07 14:38     ` Laurent Pinchart
2024-02-21 10:55       ` Sakari Ailus
2024-02-21 10:53     ` Sakari Ailus
2024-02-21 11:02       ` Laurent Pinchart
2024-02-21 11:38         ` Sakari Ailus
2024-02-21 11:19       ` Hans Verkuil
2024-02-21 11:40         ` Sakari Ailus
2024-02-21 11:48           ` Hans Verkuil
2024-02-21 12:02             ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 24/29] media: Documentation: Document how Media device resources are released Sakari Ailus
2024-02-05 15:04   ` Hans Verkuil
2024-02-07 14:43   ` Laurent Pinchart
2024-02-21 11:37     ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 25/29] media: mc: Add per-file-handle data support Sakari Ailus
2024-02-05 15:08   ` Hans Verkuil
2023-12-20 10:37 ` [PATCH v2 26/29] media: mc: Maintain a list of open file handles in a media device Sakari Ailus
2024-02-05 15:11   ` Hans Verkuil
2024-02-05 15:16     ` Laurent Pinchart
2024-02-05 15:32       ` Hans Verkuil
2024-02-05 15:41         ` Laurent Pinchart
2024-02-21 11:53           ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 27/29] media: mc: Implement best effort media device removal safety sans refcount Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 28/29] media: mc: Warn about drivers not releasing media device safely Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 29/29] media: Documentation: Document media device memory safety helper Sakari Ailus
2023-12-20 10:52 ` [PATCH v2 00/29] Media device lifetime management Laurent Pinchart
2023-12-20 11:30   ` Sakari Ailus
2024-02-07 10:55 ` Laurent Pinchart
2024-03-07 10:57   ` Sakari Ailus

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=ZebNJK7TMcBJVLv6@kekkonen.localdomain \
    --to=sakari.ailus@linux.intel.com \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox