Messages in this thread | | | Date | Wed, 8 Jul 2009 16:42:30 +0800 | Subject | Re: Possible memory leak in request_firmware() | From | Ming Lei <> |
| |
2009/7/8 David Woodhouse <dwmw2@infradead.org>: > 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.
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 <David.Woodhouse@intel.com>
-- 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/
| |