Messages in this thread | | | Subject | Re: Possible memory leak in request_firmware() | From | David Woodhouse <> | Date | Wed, 08 Jul 2009 07:28:39 +0100 |
| |
On Wed, 2009-07-08 at 12:38 +0800, Ming Lei wrote: > 2009/7/8 Catalin Marinas <catalin.marinas@arm.com>: > > 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.
I think you need to stop it from clearing fw_priv->nr_pages too. With that change, it looks correct. Thanks.
Acked-by: David Woodhouse <David.Woodhouse@intel.com>
-- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation
| |