From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Kagstrom Subject: Re: [PATCH] e100: Correct firmware memory leak Date: Mon, 30 May 2011 11:05:18 +0200 Message-ID: <20110530110518.2ee637d8@marrow.netinsight.se> References: <20110523090700.68cdf15a@marrow.netinsight.se> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Jeff Kirsher , Jesse Brandeburg , Bruce Allan , Carolyn Wyborny , Don Skidmore , Greg Rose , PJ Waskiewicz , Alex Duyck , John Ronciak To: netdev@vger.kernel.org, e1000-devel@lists.sourceforge.net Return-path: Received: from ernst.netinsight.se ([194.16.221.21]:26702 "HELO ernst.netinsight.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751164Ab1E3JF3 (ORCPT ); Mon, 30 May 2011 05:05:29 -0400 In-Reply-To: <20110523090700.68cdf15a@marrow.netinsight.se> Sender: netdev-owner@vger.kernel.org List-ID: Hi again, On Mon, 23 May 2011 09:07:00 +0200 Simon Kagstrom wrote: > kmemcheck reports > > unreferenced object 0xcfaf4f00 (size 32): > comm "ifconfig", pid 682, jiffies 87369 > backtrace: > [] save_stack_trace+0x20/0x24 > [] create_object+0x118/0x20c > [] kmemleak_alloc+0x40/0x84 > [] kmem_cache_alloc+0x114/0x1a4 > [] _request_firmware+0x3c/0x540 > [] request_firmware+0x14/0x18 > [] e100_hw_init+0xf0/0x3d8 > [] e100_up+0x38/0x16c > [] e100_open+0x20/0x54 > [] dev_open+0xcc/0x134 > [] dev_change_flags+0xb0/0x190 > [] devinet_ioctl+0x2f0/0x6fc > [] inet_ioctl+0xcc/0x104 > [] sock_ioctl+0x200/0x25c > [] vfs_ioctl+0x34/0x78 > [] do_vfs_ioctl+0x4e4/0x53c > [..] > diff --git a/drivers/net/e100.c b/drivers/net/e100.c > index b0aa9e6..f2b44ef 100644 > --- a/drivers/net/e100.c > +++ b/drivers/net/e100.c > @@ -1320,6 +1320,8 @@ static void e100_setup_ucode(struct nic *nic, struct cb *cb, > cb->u.ucode[min_size] |= cpu_to_le32((BUNDLESMALL) ? 0xFFFF : 0xFF80); > > cb->command = cpu_to_le16(cb_ucode | cb_el); > + > + release_firmware(fw); > } This patch can be dropped, I've made a mistake. I think there is a memory leak when the driver is unloaded, since nic->fw is never released, but that has to be solved in another way. It's also not as serious since it only happens on module unload, not on taking down the interface as indicated above. // Simon