On 19/08/06, Antonino A. Daplas <[email protected]> wrote:
On Sat, 2006-08-19 at 11:07 +0100, Catalin Marinas wrote:
> On 18/08/06, Michal Piotrowski <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
