[Ksummit-discuss] [TECH TOPIC] Fix devm_kzalloc, its users, or both

[Guenter Roeck]

On 08/01/2015 08:18 AM, Tejun Heo wrote:
> Hello,
>
> On Sat, Aug 01, 2015 at 02:01:02PM +0300, Laurent Pinchart wrote:
>>> Would it be possible to call the devres cleanup at this point, rather than
>>> on the remove function?
>>
>> As devres cleanup will also take care of interrupts and ioremap'ed regions I
>> don't think that would be an option. Otherwise we would have trouble when the
>> device is reprobed as resources would be busy.
>>
>> We could possibly create an API to allow drivers to keep references to some
>> devres-allocate objects, but that's arguably a hack.
>
> Another factor to consider is that even if the driver separately
> allocates e.g. memory which may be accessed after removal, it's mighty
> difficult to verify that file operations which take place post removal
> don't have any dependency on things which are released on removal.  I
> mean, we've always had a lot of drivers which are fairly confused
> about lifetime rules.
>
> devm allocated memory *might* make certain failures more obvious as
> the memory itself gets freed right away but I'd be very surprised if
> there aren't already a bunch of drivers which fail to fully isolate
> post-removal file operations regardless of devm.
>
> So, all in all, if we actually want to fix this issue, well at least
> most of it, I think the only viable way would be implementing revoke
> semantics and drain and sever all operations on removal.  Maybe it'll
> end up another devm interface.
>

Maybe that is completely nonsense, but how about something like
	devm_get(dev);
to be called whenever a file used by a device is opened, and
	devm_put(dev);
whenever it is closed ?

Guenter