[Ksummit-discuss] [TECH TOPIC] Fix devm_kzalloc, its users, or both
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Fri Jul 31 15:14:14 UTC 2015
Hello,
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
wrong, but it turned out I was unfortunately right. As the topic spans lots of
subsystems I believe it would be a good technical topic for the Kernel Summit.
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.
1. Get a device bound to its driver
2. Open the corresponding device node in userspace and keep it open
3. Unbind the device from its driver through sysfs using for instance
echo <device-name> > /sys/bus/platform/drivers/<driver-name>/unbind
(or for hotpluggable devices just unplug the device)
4. Close the device node
5. Enjoy the fireworks
While having a device node open prevents modules from being unloaded, it
doesn't prevent devices from being unbound from drivers. If the driver uses
devm_* helpers to allocate memory the memory will be freed when the device is
unbound from the driver, but that memory will still be used by any operation
touching an open device node.
Tejun Heo commented that "this really is a general lifetime management
problem. [...] If a piece of memory isn't attached to the harware side but the
userland interface side [...], that shouldn't be allocated via devm - it has
"dev" in its name for a reason."
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".
People who might be interested:
- Tejun Heo <tj at kernel.org>
- Shuah Khan <shuah.kh at samsung.com> (for the media controller devres WIP)
- Russell King <linux at arm.linux.org.uk> (for the component framework)
- Anyone who believes that managed memory allocation for driver private
structures is useful
--
Regards,
Laurent Pinchart
More information about the Ksummit-discuss
mailing list