On Tue, Aug 4, 2015 at 11:03 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:

> 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?
>

No, it does not, but I've seen a few examples with devm (mostly
devm_k*alloc) used in wrong context and causing almost-memory-leaks (i.e.
they had a chance to be eventually cleaned up, but not really).

Thanks.

-- 
Dmitry