![]() | |||||||||||||
Messages in this thread |
On Sat, 2006-08-19 at 11:07 +0100, Catalin Marinas wrote: > On 18/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote: > > I just added your "Fix memory leak in vc_resize/vc_allocate" patch to > > my series file. > > > > orphan pointer 0xc6110000 (size 12288): > > c017480e: <__kmalloc> > > c024dda4: <vc_resize> > > c020ed9c: <fbcon_startup> > > c0251028: <register_con_driver> > > c02511e0: <take_over_console> > > c020e21e: <fbcon_takeover> > > c0212b08: <fbcon_fb_registered> > > c0212ce1: <fbcon_event_notify> > > orphan pointer 0xf55b0000 (size 8208): > > c017480e: <__kmalloc> > > c0211bb8: <fbcon_set_font> > > c0251b17: <con_font_set> > > c0251c7b: <con_font_op> > > c0249a97: <vt_ioctl> > > c024432e: <tty_ioctl> > > c0189fd1: <do_ioctl> > > c018a269: <vfs_ioctl> > > The second one is probably a false positive as the stored pointer is > different from the one returned by kmalloc (there is some padding). > I'll add it to the kmemleak-false-positives patch. Yes, I think it's triggered by the padding: new_data += FONT_EXTRA_WORDS * sizeof(int); The free'ing in fbcon_do_set_font() takes into account the padding: if (old_data && (--REFCOUNT(old_data) == 0)) kfree(old_data - FONT_EXTRA_WORDS * sizeof(int)); > The first one might be a real leak. Anotonino, any idea about this? > On boot, vc->vc_screenbuf is allocated by alloc_bootmem() (vc->kmalloced == 0), so yes, there's a leak in there . But I don't think we have a way to deallocate this type of memory, so we just let it go. Tony - 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/ | ||||||||||||
| Last update: 2006-08-19 13:25 [from the cache] ©2003-2008 | |||||||||||||