Messages in this thread | | | Date | Sat, 19 Aug 2006 14:25:50 +0100 | From | "Catalin Marinas" <> | Subject | Re: [PATCH 2.6.18-rc4 00/10] Kernel memory leak detector 0.9 |
| |
On 19/08/06, Antonino A. Daplas <adaplas@pol.net> wrote: > 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: > > > 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> > > 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.
It's not the leak caused by alloc_bootmem as kmemleak doesn't track this kind of allocations. The block allocated via kmalloc in vc_resize() is reported as unreferenced. However, I think that's a false positive because it looks like the vc_screenbuf pointer is stored in vc_cons[].d->vc_screenbuf which is allocated by alloc_bootmem in con_init() and kmemleak doesn't track the alloc_bootmem blocks. I'll fix kmemleak.
Thanks.
-- Catalin - 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/
| |