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

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Tue, Aug 04, 2015 at 10:55:35AM -0700, Dmitry Torokhov wrote:
> I wonder if it would be possible to note that the current thread is going
> through probe() or remove() code path in driver core and scream if we
> encounter devm* call outside of such path. That will give false positives
> in cases when there is a legitimate mix of automatic and manual resource
> management (i.e. you rely on automatic cleanup in probe()/remove() but need
> to free/reallocate object somewhere else), but we can create another call
> for that.

Well, it's not that easy, now that we have the component helper (sorry).

The "easy" bit to implement that idea would be to add a flag to struct
device which indicates whether this device is in an active probe()
function, and use that in the devm* functions to determine whether
to warn about incorrect usage.

However, the component helper messes that up slightly, because it allows
devm usage outside of a device's probe() function, though still in a
properly controlled manner.  (Resources claimed via devm_* in the bind()
call will be released in after the corresponding unbind() call.)  This
is done using the devres groups.

So, maybe instead of "is it inside a probe" a better check should be "is
the devm* resource claim being done in an active devres group or inside
a probe".  Not forgetting that a devres group can be removed, merging
the child resource group with the parent resource group (which are
probably about the same as for resource claiming using devm_*.)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.