From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7FBE025A for ; Tue, 4 Aug 2015 17:55:38 +0000 (UTC) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B90EB14E for ; Tue, 4 Aug 2015 17:55:37 +0000 (UTC) Received: by lbbyj8 with SMTP id yj8so10653899lbb.0 for ; Tue, 04 Aug 2015 10:55:36 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20150804125556.GA5180@mwanda> References: <2111196.TG1k3f53YQ@avalon> <20150731165346.GA18984@infradead.org> <1624703.qdGzscHWSc@avalon> <20150804125556.GA5180@mwanda> Date: Tue, 4 Aug 2015 10:55:35 -0700 Message-ID: From: Dmitry Torokhov To: Dan Carpenter Content-Type: multipart/alternative; boundary=001a11c3bfac485575051c7ffee0 Cc: Shuah Khan , Russell King , ksummit-discuss@lists.linuxfoundation.org, Christoph Hellwig , Tejun Heo Subject: Re: [Ksummit-discuss] [TECH TOPIC] Fix devm_kzalloc, its users, or both List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --001a11c3bfac485575051c7ffee0 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 4, 2015 at 5:55 AM, Dan Carpenter 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. Thanks. -- Dmitry --001a11c3bfac485575051c7ffee0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 4, 2015 at 5:55 AM, Dan Carpenter <dan.carpenter@or= acle.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 b= e
> used?=C2=A0 All I remember seeing is a discussion of what the function= s do and
> what functions are available.=C2=A0 But nothing about when they should= and
> should not be used.
>

The documentation for devm_kmalloc() doesn't list common pitfall= s.=C2=A0 The
other big one which should be obvious, but happens often is freeing
devm_ memory with kfree().

/**
=C2=A0* devm_kmalloc - Resource-managed kmalloc
=C2=A0* @dev: Device to allocate memory for
=C2=A0* @size: Allocation size
=C2=A0* @gfp: Allocation gfp flags
=C2=A0*
=C2=A0* Managed kmalloc.=C2=A0 Memory allocated with this function is
=C2=A0* automatically freed on driver detach.=C2=A0 Like all other devres =C2=A0* resources, guaranteed alignment is unsigned long long.
=C2=A0*
=C2=A0* RETURNS:
=C2=A0* Pointer to allocated memory on success, NULL on failure.
=C2=A0*/
=C2=A0
I wonder if it would be poss= ible to note that the current thread is going through probe() or remove() c= ode path in driver core and scream if we encounter devm* call outside of su= ch 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 automati= c cleanup in probe()/remove() but need to free/reallocate object somewhere = else), but we can create another call for that.

Thanks.

--=C2=A0
Dmitry
--001a11c3bfac485575051c7ffee0--