On Tue, 4 Aug 2015, Dmitry Torokhov wrote:

>
>
> On Tue, Aug 4, 2015 at 5:55 AM, Dan Carpenter <dan.carpenter@oracle.com>
> wrote:
>       On Sat, Aug 01, 2015 at 01:21:09PM +0200, Julia Lawall wrote:
>       > Currently, is there any documentation about when these
>       functions can be
>       > used?  All I remember seeing is a discussion of what the
>       functions do and
>       > what functions are available.  But nothing about when they
>       should and
>       > should not be used.
>       >
>
>       The documentation for devm_kmalloc() doesn't list common
>       pitfalls.  The
>       other big one which should be obvious, but happens often is
>       freeing
>       devm_ memory with kfree().
>
>       /**
>        * devm_kmalloc - Resource-managed kmalloc
>        * @dev: Device to allocate memory for
>        * @size: Allocation size
>        * @gfp: Allocation gfp flags
>        *
>        * Managed kmalloc.  Memory allocated with this function is
>        * automatically freed on driver detach.  Like all other devres
>        * resources, guaranteed alignment is unsigned long long.
>        *
>        * RETURNS:
>        * Pointer to allocated memory on success, NULL on failure.
>        */
>
>  
> 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.

This seems easy to do with Coccinelle, at least with respect to the
functions in a single file.  I guess it doesn't solve the file operations
problem, though?