* kmemleak false positive?
@ 2009-06-25 0:11 Dave Jones
2009-06-25 9:25 ` Catalin Marinas
0 siblings, 1 reply; 8+ messages in thread
From: Dave Jones @ 2009-06-25 0:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Linux Kernel
During boot, I see the following traces from kmemleak.
They seem to be pointing at kmemleak itself. False positive?
(this is in -git22)
Dave
kmemleak: unreferenced object 0xdb804000 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804040 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804080 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb8040c0 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804100 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804140 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804180 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb8041c0 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804200 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804240 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804280 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb8042c0 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804300 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804340 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804380 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb8043c0 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804400 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804440 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804480 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb8044c0 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804500 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804540 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804580 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb8045c0 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804600 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804640 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804680 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb8046c0 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804700 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804740 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804780 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb8047c0 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804800 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804840 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804880 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb8048c0 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804900 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804940 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804980 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb8049c0 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804a00 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804a40 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804a80 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804ac0 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804b00 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804b40 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804b80 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804bc0 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804c00 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
kmemleak: unreferenced object 0xdb804c40 (size 20):
kmemleak: comm "swapper", pid 0, jiffies 4294667296
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
kmemleak: [<ffffffff>] 0xffffffff
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: kmemleak false positive?
2009-06-25 0:11 kmemleak false positive? Dave Jones
@ 2009-06-25 9:25 ` Catalin Marinas
2009-06-25 14:56 ` Dave Jones
0 siblings, 1 reply; 8+ messages in thread
From: Catalin Marinas @ 2009-06-25 9:25 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel
On Wed, 2009-06-24 at 20:11 -0400, Dave Jones wrote:
> During boot, I see the following traces from kmemleak.
> They seem to be pointing at kmemleak itself.
The stack trace includes kmemleak_alloc (I skipped one level but
depending on gcc inlining it may need two) but the allocation happened
via debug_objects_mem_init(), more exactly the fill_pool() in
lib/debugobjects.c
> False positive?
[...]
> kmemleak: unreferenced object 0xdb804000 (size 20):
> kmemleak: comm "swapper", pid 0, jiffies 4294667296
> kmemleak: backtrace:
> kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
> kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
> kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
> kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
> kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
> kmemleak: [<ffffffff>] 0xffffffff
It could be a false positive. Do you get some "kmemleak: referenced"
messages as well at a later time? In this case, it is just transient
"leak", caused maybe by pointers stored on the stack or registers.
Is the obj_pool in lib/debugobjects.c supposed to be empty at the end of
the test and all objects freed? The obj_pool is a list and the first
elements in this list are from obj_static_pool, which is __initdata.
Objects added to the list may be referred by chaining with the
obj_static_pool objects but kmemleak doesn't scan __initdata as this is
usually freed before kmemleak does its first scan. So, if it is just a
transient "leak", kmemleak should later report "kmemleak: referenced" if
a kmem_cache_free() is called on any of the reported objects.
You can mount debugfs on /sys/kerne/debug and read the kmemleak file in
there (it triggers a new scan as well). You can also echo stack=on to
the above kmemleak file to enable kernel stack scanning.
Could you send me your config options for DEBUG_OBJECTS_* and slab
allocator so I can try to reproduce this?
Thanks.
--
Catalin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: kmemleak false positive?
2009-06-25 9:25 ` Catalin Marinas
@ 2009-06-25 14:56 ` Dave Jones
2009-06-25 15:25 ` Catalin Marinas
0 siblings, 1 reply; 8+ messages in thread
From: Dave Jones @ 2009-06-25 14:56 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Linux Kernel
On Thu, Jun 25, 2009 at 10:25:17AM +0100, Catalin Marinas wrote:
> > kmemleak: backtrace:
> > kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
> > kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
> > kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
> > kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
> > kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
> > kmemleak: [<ffffffff>] 0xffffffff
>
> It could be a false positive. Do you get some "kmemleak: referenced"
> messages as well at a later time? In this case, it is just transient
> "leak", caused maybe by pointers stored on the stack or registers.
Yes, some time later.
> Is the obj_pool in lib/debugobjects.c supposed to be empty at the end of
> the test and all objects freed? The obj_pool is a list and the first
> elements in this list are from obj_static_pool, which is __initdata.
> Objects added to the list may be referred by chaining with the
> obj_static_pool objects but kmemleak doesn't scan __initdata as this is
> usually freed before kmemleak does its first scan. So, if it is just a
> transient "leak", kmemleak should later report "kmemleak: referenced" if
> a kmem_cache_free() is called on any of the reported objects.
Hmm, it's pretty noisy, and everything it's found so far looks to be
a false positive.
> You can mount debugfs on /sys/kerne/debug and read the kmemleak file in
> there (it triggers a new scan as well).
Currently prints the acpi traces I already posted.
> You can also echo stack=on to
> the above kmemleak file to enable kernel stack scanning.
>
> Could you send me your config options for DEBUG_OBJECTS_* and slab
> allocator so I can try to reproduce this?
CONFIG_DEBUG_OBJECTS=y
# CONFIG_DEBUG_OBJECTS_SELFTEST is not set
CONFIG_DEBUG_OBJECTS_FREE=y
CONFIG_DEBUG_OBJECTS_TIMERS=y
CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
Dave
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: kmemleak false positive?
2009-06-25 14:56 ` Dave Jones
@ 2009-06-25 15:25 ` Catalin Marinas
2009-06-25 15:40 ` Dave Jones
0 siblings, 1 reply; 8+ messages in thread
From: Catalin Marinas @ 2009-06-25 15:25 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel
On Thu, 2009-06-25 at 10:56 -0400, Dave Jones wrote:
> On Thu, Jun 25, 2009 at 10:25:17AM +0100, Catalin Marinas wrote:
> > > kmemleak: backtrace:
> > > kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
> > > kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
> > > kmemleak: [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
> > > kmemleak: [<c0a86a62>] start_kernel+0x2da/0x38d
> > > kmemleak: [<c0a86090>] i386_start_kernel+0x7f/0x98
> > > kmemleak: [<ffffffff>] 0xffffffff
> >
> > It could be a false positive. Do you get some "kmemleak: referenced"
> > messages as well at a later time? In this case, it is just transient
> > "leak", caused maybe by pointers stored on the stack or registers.
>
> Yes, some time later.
[...]
> Hmm, it's pretty noisy, and everything it's found so far looks to be
> a false positive.
In this case, it would make sense to enable task stacks scanning by
default:
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 17096d1..a38418a 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -194,7 +194,7 @@ static unsigned long jiffies_min_age;
/* delay between automatic memory scannings */
static signed long jiffies_scan_wait;
/* enables or disables the task stacks scanning */
-static int kmemleak_stack_scan;
+static int kmemleak_stack_scan = 1;
/* mutex protecting the memory scanning */
static DEFINE_MUTEX(scan_mutex);
/* mutex protecting the access to the /sys/kernel/debug/kmemleak file */
> > You can mount debugfs on /sys/kerne/debug and read the kmemleak file in
> > there (it triggers a new scan as well).
>
> Currently prints the acpi traces I already posted.
If they are still consistently shown with stack=on, it could be a leak.
--
Catalin
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: kmemleak false positive?
2009-06-25 15:25 ` Catalin Marinas
@ 2009-06-25 15:40 ` Dave Jones
2009-06-25 17:00 ` Catalin Marinas
2009-06-25 19:49 ` Stephen Smalley
0 siblings, 2 replies; 8+ messages in thread
From: Dave Jones @ 2009-06-25 15:40 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Linux Kernel
On Thu, Jun 25, 2009 at 04:25:39PM +0100, Catalin Marinas wrote:
> > Hmm, it's pretty noisy, and everything it's found so far looks to be
> > a false positive.
>
> In this case, it would make sense to enable task stacks scanning by
> default:
>
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index 17096d1..a38418a 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -194,7 +194,7 @@ static unsigned long jiffies_min_age;
> /* delay between automatic memory scannings */
> static signed long jiffies_scan_wait;
> /* enables or disables the task stacks scanning */
> -static int kmemleak_stack_scan;
> +static int kmemleak_stack_scan = 1;
heh, I just did the same patch for the rawhide kernel builds.
> > > You can mount debugfs on /sys/kerne/debug and read the kmemleak file in
> > > there (it triggers a new scan as well).
> >
> > Currently prints the acpi traces I already posted.
>
> If they are still consistently shown with stack=on, it could be a leak.
Could be, though as you mentioned, with ACPI it's really hard to tell.
Here's another case (with stack scanning on btw) which looks odd..
kmemleak: unreferenced object 0xd86ba000 (size 16):
kmemleak: comm "init", pid 1, jiffies 4294683556
kmemleak: backtrace:
kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
kmemleak: [<c05cdfdc>] avtab_insertf+0xd6/0x140
kmemleak: [<c05ce3d7>] avtab_read_item+0x26a/0x284
kmemleak: [<c05ce5a5>] avtab_read+0x82/0xe5
kmemleak: [<c05d0618>] policydb_read+0x40c/0x1028
kmemleak: [<c05d459d>] security_load_policy+0x57/0x37c
kmemleak: [<c05c9995>] sel_write_load+0xb2/0x54a
kmemleak: [<c0500186>] vfs_write+0x9f/0x10f
kmemleak: [<c05002e1>] sys_write+0x58/0x8d
kmemleak: [<c040a8eb>] sysenter_do_call+0x12/0x38
kmemleak: [<ffffffff>] 0xffffffff
I looked over the SELinux code, and couldn't see an obvious leak.
Eric Paris came to the same conclusion.
Dave
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: kmemleak false positive?
2009-06-25 15:40 ` Dave Jones
@ 2009-06-25 17:00 ` Catalin Marinas
2009-06-25 19:31 ` Dave Jones
2009-06-25 19:49 ` Stephen Smalley
1 sibling, 1 reply; 8+ messages in thread
From: Catalin Marinas @ 2009-06-25 17:00 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel
On Thu, 2009-06-25 at 11:40 -0400, Dave Jones wrote:
> Here's another case (with stack scanning on btw) which looks odd..
>
> kmemleak: unreferenced object 0xd86ba000 (size 16):
> kmemleak: comm "init", pid 1, jiffies 4294683556
> kmemleak: backtrace:
> kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
> kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
> kmemleak: [<c05cdfdc>] avtab_insertf+0xd6/0x140
> kmemleak: [<c05ce3d7>] avtab_read_item+0x26a/0x284
> kmemleak: [<c05ce5a5>] avtab_read+0x82/0xe5
> kmemleak: [<c05d0618>] policydb_read+0x40c/0x1028
> kmemleak: [<c05d459d>] security_load_policy+0x57/0x37c
> kmemleak: [<c05c9995>] sel_write_load+0xb2/0x54a
> kmemleak: [<c0500186>] vfs_write+0x9f/0x10f
> kmemleak: [<c05002e1>] sys_write+0x58/0x8d
> kmemleak: [<c040a8eb>] sysenter_do_call+0x12/0x38
> kmemleak: [<ffffffff>] 0xffffffff
>
> I looked over the SELinux code, and couldn't see an obvious leak.
> Eric Paris came to the same conclusion.
How long does a memory scanning take (i.e. time cat debug/kmemleak) on
your platform? Another tweak is to increase MSECS_MIN_AGE to something
like 1 minute or more. Especially on SMP, some newly allocated objects
may be in registers and reported as leaks.
I'll have a look at the initial colour assigned to newly allocated
objects. Currently the objects allocated during a scan have no colour so
that they are not reported. However, they are not scanned either so
other object pointers allocated before the scan started may be stored in
those new objects.
--
Catalin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: kmemleak false positive?
2009-06-25 17:00 ` Catalin Marinas
@ 2009-06-25 19:31 ` Dave Jones
0 siblings, 0 replies; 8+ messages in thread
From: Dave Jones @ 2009-06-25 19:31 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Linux Kernel
On Thu, Jun 25, 2009 at 06:00:02PM +0100, Catalin Marinas wrote:
> On Thu, 2009-06-25 at 11:40 -0400, Dave Jones wrote:
> > Here's another case (with stack scanning on btw) which looks odd..
> >
> > kmemleak: unreferenced object 0xd86ba000 (size 16):
> > kmemleak: comm "init", pid 1, jiffies 4294683556
> > kmemleak: backtrace:
> > kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
> > kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
> > kmemleak: [<c05cdfdc>] avtab_insertf+0xd6/0x140
> > kmemleak: [<c05ce3d7>] avtab_read_item+0x26a/0x284
> > kmemleak: [<c05ce5a5>] avtab_read+0x82/0xe5
> > kmemleak: [<c05d0618>] policydb_read+0x40c/0x1028
> > kmemleak: [<c05d459d>] security_load_policy+0x57/0x37c
> > kmemleak: [<c05c9995>] sel_write_load+0xb2/0x54a
> > kmemleak: [<c0500186>] vfs_write+0x9f/0x10f
> > kmemleak: [<c05002e1>] sys_write+0x58/0x8d
> > kmemleak: [<c040a8eb>] sysenter_do_call+0x12/0x38
> > kmemleak: [<ffffffff>] 0xffffffff
> >
> > I looked over the SELinux code, and couldn't see an obvious leak.
> > Eric Paris came to the same conclusion.
>
> How long does a memory scanning take (i.e. time cat debug/kmemleak) on
> your platform? Another tweak is to increase MSECS_MIN_AGE to something
> like 1 minute or more. Especially on SMP, some newly allocated objects
> may be in registers and reported as leaks.
0.00user 16.15system 0:33.38elapsed 48%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+158minor)pagefaults 0swaps
This is a VIA C3 with 512MB of RAM.
Dave
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: kmemleak false positive?
2009-06-25 15:40 ` Dave Jones
2009-06-25 17:00 ` Catalin Marinas
@ 2009-06-25 19:49 ` Stephen Smalley
1 sibling, 0 replies; 8+ messages in thread
From: Stephen Smalley @ 2009-06-25 19:49 UTC (permalink / raw)
To: Dave Jones
Cc: Catalin Marinas, Linux Kernel, Eric Paris, Kaigai Kohei,
James Morris
On Thu, 2009-06-25 at 11:40 -0400, Dave Jones wrote:
> On Thu, Jun 25, 2009 at 04:25:39PM +0100, Catalin Marinas wrote:
> > > Hmm, it's pretty noisy, and everything it's found so far looks to be
> > > a false positive.
> >
> > In this case, it would make sense to enable task stacks scanning by
> > default:
> >
> > diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> > index 17096d1..a38418a 100644
> > --- a/mm/kmemleak.c
> > +++ b/mm/kmemleak.c
> > @@ -194,7 +194,7 @@ static unsigned long jiffies_min_age;
> > /* delay between automatic memory scannings */
> > static signed long jiffies_scan_wait;
> > /* enables or disables the task stacks scanning */
> > -static int kmemleak_stack_scan;
> > +static int kmemleak_stack_scan = 1;
>
> heh, I just did the same patch for the rawhide kernel builds.
>
> > > > You can mount debugfs on /sys/kerne/debug and read the kmemleak file in
> > > > there (it triggers a new scan as well).
> > >
> > > Currently prints the acpi traces I already posted.
> >
> > If they are still consistently shown with stack=on, it could be a leak.
>
> Could be, though as you mentioned, with ACPI it's really hard to tell.
>
> Here's another case (with stack scanning on btw) which looks odd..
>
> kmemleak: unreferenced object 0xd86ba000 (size 16):
> kmemleak: comm "init", pid 1, jiffies 4294683556
> kmemleak: backtrace:
> kmemleak: [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
> kmemleak: [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
> kmemleak: [<c05cdfdc>] avtab_insertf+0xd6/0x140
> kmemleak: [<c05ce3d7>] avtab_read_item+0x26a/0x284
> kmemleak: [<c05ce5a5>] avtab_read+0x82/0xe5
> kmemleak: [<c05d0618>] policydb_read+0x40c/0x1028
> kmemleak: [<c05d459d>] security_load_policy+0x57/0x37c
> kmemleak: [<c05c9995>] sel_write_load+0xb2/0x54a
> kmemleak: [<c0500186>] vfs_write+0x9f/0x10f
> kmemleak: [<c05002e1>] sys_write+0x58/0x8d
> kmemleak: [<c040a8eb>] sysenter_do_call+0x12/0x38
> kmemleak: [<ffffffff>] 0xffffffff
>
> I looked over the SELinux code, and couldn't see an obvious leak.
> Eric Paris came to the same conclusion.
I suspect it is a false positive caused by the current odd way in which
we update the policydb. So I would expect it to go away when we get
around to rewriting that code, already on our todo list.
However, KaiGai Kohei noticed that /sys/kernel/slab/avtab_node/objects
seems to grow upon repeated load_policy invocations (of the same policy)
for some kernels (e.g. F11 kernel) while remaining constant for the
rawhide kernel.
# for i in `seq 1 100`
> do
> load_policy
> cat /sys/kernel/slab/avtab_node/objects
> done
--
Stephen Smalley
National Security Agency
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-06-25 19:50 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-06-25 0:11 kmemleak false positive? Dave Jones
2009-06-25 9:25 ` Catalin Marinas
2009-06-25 14:56 ` Dave Jones
2009-06-25 15:25 ` Catalin Marinas
2009-06-25 15:40 ` Dave Jones
2009-06-25 17:00 ` Catalin Marinas
2009-06-25 19:31 ` Dave Jones
2009-06-25 19:49 ` Stephen Smalley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox