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@xxxxxxxxxxxxxxx> > >> --- > >> > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
