From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: [PATCH 3/3] sound/soc/soc-core.c: drop kfree of devm_kzalloc's data Date: Sat, 4 Aug 2012 15:32:04 +0100 Message-ID: <20120804143200.GD15691@opensource.wolfsonmicro.com> References: <1344081632-4729-3-git-send-email-Julia.Lawall@lip6.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from opensource.wolfsonmicro.com (opensource.wolfsonmicro.com [80.75.67.52]) by alsa0.perex.cz (Postfix) with ESMTP id C0379265B66 for ; Mon, 6 Aug 2012 11:53:29 +0200 (CEST) Content-Disposition: inline In-Reply-To: <1344081632-4729-3-git-send-email-Julia.Lawall@lip6.fr> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Julia Lawall Cc: alsa-devel@alsa-project.org, Takashi Iwai , kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, matthias@kaehlcke.net, Liam Girdwood List-Id: alsa-devel@alsa-project.org On Sat, Aug 04, 2012 at 02:00:32PM +0200, Julia Lawall wrote: > From: Julia Lawall > > Using kfree to free data allocated with devm_kzalloc causes double frees. > > The semantic patch that fixes this problem is as follows: > (http://coccinelle.lip6.fr/) Might it make more sense to devm_kfree() them? If we don't expect to immediately abort driver instantiation it'll save having them lying around for the entire lifetime of the device even if they're not strictly leaked. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Date: Sat, 04 Aug 2012 14:32:04 +0000 Subject: Re: [PATCH 3/3] sound/soc/soc-core.c: drop kfree of devm_kzalloc's data Message-Id: <20120804143200.GD15691@opensource.wolfsonmicro.com> List-Id: References: <1344081632-4729-3-git-send-email-Julia.Lawall@lip6.fr> In-Reply-To: <1344081632-4729-3-git-send-email-Julia.Lawall@lip6.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Julia Lawall Cc: alsa-devel@alsa-project.org, Takashi Iwai , kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, matthias@kaehlcke.net, Liam Girdwood On Sat, Aug 04, 2012 at 02:00:32PM +0200, Julia Lawall wrote: > From: Julia Lawall > > Using kfree to free data allocated with devm_kzalloc causes double frees. > > The semantic patch that fixes this problem is as follows: > (http://coccinelle.lip6.fr/) Might it make more sense to devm_kfree() them? If we don't expect to immediately abort driver instantiation it'll save having them lying around for the entire lifetime of the device even if they're not strictly leaked. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754172Ab2HFKXS (ORCPT ); Mon, 6 Aug 2012 06:23:18 -0400 Received: from opensource.wolfsonmicro.com ([80.75.67.52]:34964 "EHLO opensource.wolfsonmicro.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751316Ab2HFKXQ (ORCPT ); Mon, 6 Aug 2012 06:23:16 -0400 Date: Sat, 4 Aug 2012 15:32:04 +0100 From: Mark Brown To: Julia Lawall Cc: Liam Girdwood , matthias@kaehlcke.net, kernel-janitors@vger.kernel.org, Jaroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] sound/soc/soc-core.c: drop kfree of devm_kzalloc's data Message-ID: <20120804143200.GD15691@opensource.wolfsonmicro.com> References: <1344081632-4729-3-git-send-email-Julia.Lawall@lip6.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1344081632-4729-3-git-send-email-Julia.Lawall@lip6.fr> X-Cookie: You will triumph over your enemy. User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 04, 2012 at 02:00:32PM +0200, Julia Lawall wrote: > From: Julia Lawall > > Using kfree to free data allocated with devm_kzalloc causes double frees. > > The semantic patch that fixes this problem is as follows: > (http://coccinelle.lip6.fr/) Might it make more sense to devm_kfree() them? If we don't expect to immediately abort driver instantiation it'll save having them lying around for the entire lifetime of the device even if they're not strictly leaked.