Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759363AbZGHImr (ORCPT ); Wed, 8 Jul 2009 04:42:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758292AbZGHImd (ORCPT ); Wed, 8 Jul 2009 04:42:33 -0400 Received: from wf-out-1314.google.com ([209.85.200.174]:23798 "EHLO wf-out-1314.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758296AbZGHIma convert rfc822-to-8bit (ORCPT ); Wed, 8 Jul 2009 04:42:30 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nh1fz6UF1GYEMtF1f0J5beWtKPg4fSOjsehG0AXfW2Z9vfn8BD9nLcSDTgG2NHkp1N Rq2wSllxjSpmeipKEKgqWxeCOGEfS4fGPDLI3k4JFWr3RTkDVg+fZkuBYnNykDtH1m6U MmpW3HbgAeRBBL3U1gGyx1HNusqFh+SN0b6D0= MIME-Version: 1.0 In-Reply-To: <1247034519.15903.3.camel@macbook.infradead.org> References: <1246979820.9451.71.camel@pc1117.cambridge.arm.com> <20090707190125.61920d00@gondolin> <1247003445.5710.7.camel@pc1117.cambridge.arm.com> <1247034519.15903.3.camel@macbook.infradead.org> Date: Wed, 8 Jul 2009 16:42:30 +0800 Message-ID: Subject: Re: Possible memory leak in request_firmware() From: Ming Lei To: David Woodhouse Cc: Catalin Marinas , Cornelia Huck , Greg Kroah-Hartman , linux-kernel , Sachin Sant Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1800 Lines: 52 2009/7/8 David Woodhouse : > On Wed, 2009-07-08 at 12:38 +0800, Ming Lei wrote: >> 2009/7/8 Catalin Marinas : >> > On Tue, 2009-07-07 at 19:01 +0200, Cornelia Huck wrote: >> > >> > There is one more leak in this area which I couldn't figure out where it >> > should be freed: >> > >> > unreferenced object 0xc353e530 (size 512): >> > ?comm "cat", pid 3130, jiffies 4294903232 >> > ?backtrace: >> > ? ?[] create_object+0xfa/0x250 >> > ? ?[] kmemleak_alloc+0x5d/0x70 >> > ? ?[] __kmalloc+0x10d/0x210 >> > ? ?[] firmware_data_write+0x1df/0x270 >> > ? ?[] write+0x13a/0x1b0 >> > ? ?[] vfs_write+0x9c/0x190 >> > ? ?[] sys_write+0x3d/0x70 >> > ? ?[] sysenter_do_call+0x12/0x38 >> > ? ?[] 0xffffffff >> > >> > Any idea? It looks like this is the kmalloc() in fw_realloc_buffer() >> > (inlined in firmware_data_write). >> >> I guess the leak is introduced in commit : >> ? ? ? ? ? ? ?commit ? 6e03a201bbe8137487f340d26aa662110e324b20 >> ? ? ? ? ? ? ?firmware: speed up request_firmware(), v3 >> >> The attachment patch may fix the leak, please test and verify it. >> Thanks. > > I think you need to stop it from clearing fw_priv->nr_pages too. > With that change, it looks correct. Thanks. IMHO, No. If nr_pages is not cleaned, pages pointed by pages[] will be freed by fw_dev_release, but they should be freed by vfree() in release_firmware. Right? > > Acked-by: David Woodhouse -- Lei Ming -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/