Hi Jacopo, On Tuesday 02 May 2017 11:48:42 jmondi wrote: > On Thu, Apr 27, 2017 at 02:47:14PM +0300, Laurent Pinchart wrote: > > Hi Jacopo, > > [snip] > > > > + pcdev = devm_kzalloc(&pdev->dev, sizeof(*pcdev), GFP_KERNEL); > > > > devm_kzalloc() is harmful here. You're embedding a struct video_device > > instead struct sh_ceu_dev, and the video device can outlive the platform > > driver remove() call if the device node is kept open by userspace when > > the device is removed. You should use kzalloc() and implement a .release > > callback for the video_device to kfree() the memory. > > Does this apply to video_unregister_device() as well? > Should I keep it registered after platform driver removal? No, the video device must be unregistered in the platform driver's remove() callback. As explained in my previous reply the driver private data structure can still be reachable if a userspace application has the device node opened when it gets unregistered, so you can't free it in the remove() callback. > Other drivers (eg atmel-isc and pxa_camera) unregister the video > device in their sensor unbind callbacks. > As video device has pointer to fops embedded, if we unregister it at > sensor unbind time, does the ipotetical application having an open > reference to the device node lose the ability to properly close it? An application will always be able to close an open file handle, and that will always end up in the v4l2_file_operations release() handler, which can access the driver's private data structure (including the video_device instance it embeds). That's why you can't free the memory before the last file handle is closed. -- Regards, Laurent Pinchart
