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

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2213 bytes --]

On Fri, Jul 31, 2015 at 06:14:14PM +0300, Laurent Pinchart wrote:

> It recently came to my attention that the way devm_kzalloc() is used by most
> drivers is broken. I've raised the topic on LKML (see
> http://lkml.org/lkml/2015/7/14/741) in the hope that my findings were simply

lkml.org is down (again) - can you please provide a subject line?

> The issue occurs when drivers use devm_kzalloc() to allocate data structures 
> that can be accessed through file operations on a device node. The following 
> sequence of events will then lead to a crash.

Like Julia says I'm not sure this is really related to devm_ - I would
really expect that the majority of users were already broken prior to
the conversion to devm_ since the natural thing is to free things in the
remove() function which has exactly the same issues, the main problem
here is that the file open after device is removed case is rare for most
devices and requires somewhat obscure handling.

> While I agree that this is how devres operates today, I'm not sure we should 
> throw the baby out with the bath water. Using devm_kzalloc() as currently done  
> has value, and reverting drivers to the pre-devm memory allocation code would 
> make error handling and cleanup code paths more complex again.

> Should we introduce a managed allocator for that purpose that would have a 
> lifespan explicitly handled by drivers (or, even better, handled automatically 
> in a way that would suit our use cases) ? Tejun commented that "a better 
> approach would be implementing generic revoke feature and sever open files on 
> driver detach so that everything can be shutdown then".

Tejun's suggestion seems like the most robust thing here - allocation
issues are only going to be one of the problems with userspace accessing
devices that are going away and there's a complexity cost from having
the partially destroyed cases around.  Off the top of my head there's
anything that attempts to access the hardware if it's genuinely gone
away rather than just been soft unbound for example.  If the device can
just invalidate all open files on the way out then that's going to be
exactly what most things want.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]