Re: Possible memory leak in request_firmware()

From: Ming Lei
Date: Wed Jul 08 2009 - 00:38:18 EST


2009/7/8 Catalin Marinas <catalin.marinas@xxxxxxx>:
> 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:
>    [<c01e6f6a>] create_object+0xfa/0x250
>    [<c01e753d>] kmemleak_alloc+0x5d/0x70
>    [<c01e223d>] __kmalloc+0x10d/0x210
>    [<c03b2d2f>] firmware_data_write+0x1df/0x270
>    [<c024163a>] write+0x13a/0x1b0
>    [<c01eae1c>] vfs_write+0x9c/0x190
>    [<c01eafcd>] sys_write+0x3d/0x70
>    [<c010319c>] sysenter_do_call+0x12/0x38
>    [<ffffffff>] 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.


--
Lei Ming
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 2da4803..271dc6b 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -180,7 +180,6 @@ static ssize_t firmware_loading_store(struct device *dev,
goto err;
}
/* Pages will be freed by vfree() */
- fw_priv->pages = NULL;
fw_priv->page_array_size = 0;
fw_priv->nr_pages = 0;
complete(&fw_priv->completion);