From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
linux-media@vger.kernel.org, hverkuil@xs4all.nl,
mchehab@osg.samsung.com, shuahkh@osg.samsung.com
Subject: Re: [RFC v3 21/21] omap3isp: Don't rely on devm for memory resource management
Date: Thu, 15 Dec 2016 13:42:44 +0200 [thread overview]
Message-ID: <3081773.GUJA4mrXhH@avalon> (raw)
In-Reply-To: <20161215113956.GF16630@valkosipuli.retiisi.org.uk>
Hi Sakari,
On Thursday 15 Dec 2016 13:39:56 Sakari Ailus wrote:
> On Thu, Dec 15, 2016 at 01:23:50PM +0200, Laurent Pinchart wrote:
> > On Saturday 27 Aug 2016 02:43:29 Sakari Ailus wrote:
> >> devm functions are fine for managing resources that are directly related
> >> to the device at hand and that have no other dependencies. However, a
> >> process holding a file handle to a device created by a driver for a
> >> device may result in the file handle left behind after the device is long
> >> gone. This will result in accessing released (and potentially
> >> reallocated) memory.
> >>
> >> Instead, rely on the media device which will stick around until all
> >> users are gone.
> >
> > Could you move this patch to the beginning of the series to show that
> > converting the driver away from devm_* isn't enough to fix the problem
> > that the series tries to address ?
>
> Unfortunately not. The patch depends on the previous patch; the
> isp_release() function is called once the last user of the device nodes (MC,
> V4L2 and V4L2 sub-dev) is gone.
You can split that part out. The devm_* removal is independent and could be
moved to the beginning of the series.
> I'll also see what could be done based on Mauro's suggestion to move
> streamoff to device removal. That could fix a number of problems (but not
> all of them).
I'll reply to that separately but it's not the best idea.
> >> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> >> ---
> >>
> >> drivers/media/platform/omap3isp/isp.c | 38 +++++++++++++-------
> >> drivers/media/platform/omap3isp/ispccp2.c | 3 ++-
> >> drivers/media/platform/omap3isp/isph3a_aewb.c | 20 +++++++++-----
> >> drivers/media/platform/omap3isp/isph3a_af.c | 20 +++++++++-----
> >> drivers/media/platform/omap3isp/isphist.c | 5 ++--
> >> drivers/media/platform/omap3isp/ispstat.c | 2 ++
> >> 6 files changed, 63 insertions(+), 25 deletions(-)
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2016-12-15 11:42 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-26 23:43 [RFC v3 00/21] Make use of kref in media device, grab references as needed Sakari Ailus
2016-08-26 23:43 ` [RFC v3 01/21] Revert "[media] media: fix media devnode ioctl/syscall and unregister race" Sakari Ailus
2016-08-26 23:43 ` [RFC v3 02/21] Revert "[media] media: fix use-after-free in cdev_put() when app exits after driver unbind" Sakari Ailus
2016-08-26 23:43 ` [RFC v3 03/21] Revert "[media] media-device: dynamically allocate struct media_devnode" Sakari Ailus
2016-08-26 23:43 ` [RFC v3 04/21] media: Remove useless curly braces and parentheses Sakari Ailus
2016-08-26 23:43 ` [RFC v3 05/21] media: devnode: Rename mdev argument as devnode Sakari Ailus
2016-08-26 23:43 ` [RFC v3 06/21] media device: Drop nop release callback Sakari Ailus
2016-08-26 23:43 ` [RFC v3 07/21] media-device: Make devnode.dev->kobj parent of devnode.cdev Sakari Ailus
2016-08-26 23:43 ` [RFC v3 08/21] media: Enable allocating the media device dynamically Sakari Ailus
2016-08-26 23:43 ` [RFC v3 09/21] media: Split initialising and adding media devnode Sakari Ailus
2016-08-26 23:43 ` [RFC v3 10/21] media: Shuffle functions around Sakari Ailus
2016-08-26 23:43 ` [RFC v3 11/21] media device: Refcount the media device Sakari Ailus
2016-08-26 23:43 ` [RFC v3 12/21] media device: Initialise media devnode in media_device_init() Sakari Ailus
2016-08-26 23:43 ` [RFC v3 13/21] media device: Deprecate media_device_{init,cleanup}() for drivers Sakari Ailus
2016-08-26 23:43 ` [RFC v3 14/21] media device: Get the media device driver's device Sakari Ailus
2016-08-26 23:43 ` [RFC v3 15/21] media: Provide a way to the driver to set a private pointer Sakari Ailus
2016-08-26 23:43 ` [RFC v3 16/21] media: Add release callback for media device Sakari Ailus
2016-08-26 23:43 ` [RFC v3 17/21] v4l: Acquire a reference to the media device for every video device Sakari Ailus
2016-08-26 23:43 ` [RFC v3 18/21] media-device: Postpone graph object removal until free Sakari Ailus
2016-08-26 23:43 ` [RFC v3 19/21] omap3isp: Allocate the media device dynamically Sakari Ailus
2016-08-26 23:43 ` [RFC v3 20/21] omap3isp: Release the isp device struct by media device callback Sakari Ailus
2016-08-26 23:43 ` [RFC v3 21/21] omap3isp: Don't rely on devm for memory resource management Sakari Ailus
2016-12-15 11:23 ` Laurent Pinchart
2016-12-15 11:39 ` Sakari Ailus
2016-12-15 11:42 ` Laurent Pinchart [this message]
2016-12-15 11:45 ` Sakari Ailus
2016-12-15 11:57 ` Laurent Pinchart
2016-12-15 19:17 ` Shuah Khan
2016-12-16 13:32 ` Sakari Ailus
2016-12-16 14:39 ` Shuah Khan
2016-11-07 20:16 ` [RFC v3 00/21] Make use of kref in media device, grab references as needed Shuah Khan
2016-11-08 8:19 ` Sakari Ailus
2016-11-09 16:49 ` Shuah Khan
2016-11-09 17:00 ` Shuah Khan
2016-11-09 17:46 ` Mauro Carvalho Chehab
2016-11-14 13:27 ` Sakari Ailus
2016-11-22 17:44 ` Mauro Carvalho Chehab
2016-11-22 18:13 ` Hans Verkuil
2016-11-22 18:41 ` Shuah Khan
2016-11-22 22:56 ` Shuah Khan
2016-11-28 10:45 ` Sakari Ailus
2016-11-29 11:13 ` Mauro Carvalho Chehab
2016-12-13 10:53 ` Sakari Ailus
2016-12-13 12:24 ` Mauro Carvalho Chehab
2016-12-13 22:23 ` Shuah Khan
2016-12-15 10:39 ` Laurent Pinchart
2016-12-15 14:56 ` Shuah Khan
2016-12-16 16:58 ` Laurent Pinchart
2016-12-15 11:30 ` Sakari Ailus
2016-12-15 12:56 ` Laurent Pinchart
2016-12-15 14:03 ` Hans Verkuil
2016-12-15 14:32 ` Mauro Carvalho Chehab
2016-12-15 14:45 ` Hans Verkuil
2016-12-15 15:45 ` Mauro Carvalho Chehab
2016-12-15 16:07 ` Hans Verkuil
2016-12-16 16:47 ` Laurent Pinchart
2016-12-16 16:43 ` Laurent Pinchart
2016-12-15 14:45 ` Shuah Khan
2016-12-15 15:26 ` Hans Verkuil
2016-12-15 16:06 ` Shuah Khan
2016-12-15 16:28 ` Hans Verkuil
2016-12-15 17:09 ` Shuah Khan
2016-12-15 17:25 ` Mauro Carvalho Chehab
2016-12-15 17:51 ` Shuah Khan
2016-12-16 10:11 ` Hans Verkuil
2016-12-16 10:57 ` Mauro Carvalho Chehab
2016-12-16 11:27 ` Hans Verkuil
2016-12-16 12:00 ` Mauro Carvalho Chehab
2016-12-16 14:45 ` Hans Verkuil
2016-12-19 9:28 ` Media summit in Feb? - Was: " Mauro Carvalho Chehab
2016-12-21 1:31 ` Mauro Carvalho Chehab
2016-12-21 14:27 ` Shuah Khan
2016-12-22 17:47 ` Laurent Pinchart
2016-12-22 20:43 ` Mauro Carvalho Chehab
2016-12-16 10:03 ` Hans Verkuil
2016-12-16 10:12 ` Mauro Carvalho Chehab
2016-12-23 18:13 ` Laurent Pinchart
2016-12-15 17:08 ` Mauro Carvalho Chehab
2016-12-23 17:55 ` Laurent Pinchart
2016-12-23 17:48 ` Laurent Pinchart
2016-12-23 17:27 ` Laurent Pinchart
2016-12-16 15:07 ` Sakari Ailus
2016-12-16 16:34 ` Laurent Pinchart
2016-12-19 9:46 ` Mauro Carvalho Chehab
2017-01-02 7:53 ` Sakari Ailus
2017-01-24 10:49 ` Mauro Carvalho Chehab
2017-01-25 11:02 ` Sakari Ailus
2017-01-26 9:10 ` Mauro Carvalho Chehab
2017-05-30 23:41 ` Shuah Khan
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=3081773.GUJA4mrXhH@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=sakari.ailus@iki.fi \
--cc=sakari.ailus@linux.intel.com \
--cc=shuahkh@osg.samsung.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