* How to analyze kmemleak message?
@ 2009-02-23 8:24 Tetsuo Handa
2009-02-23 9:40 ` Pekka Enberg
0 siblings, 1 reply; 6+ messages in thread
From: Tetsuo Handa @ 2009-02-23 8:24 UTC (permalink / raw)
To: linux-kernel
Hello.
I got this message with linux-2.6.29-rc5-next-20090220 .
[ 89.856902] unreferenced object 0xf7009180 (size 124):
[ 89.857484] comm "swapper", pid 0, jiffies 4294892306
[ 89.857484] backtrace:
[ 89.857484] [<c0230695>] create_object+0x155/0x2c0
[ 89.857484] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
[ 89.857484] [<c0228581>] kmem_cache_alloc+0x191/0x220
[ 89.857484] [<c025dc23>] alloc_vfsmnt+0x23/0x170
[ 89.857484] [<c023b632>] vfs_kern_mount+0x52/0x230
[ 89.857484] [<c023ba2a>] kern_mount_data+0x1a/0x20
[ 89.857484] [<c126a03e>] bdev_cache_init+0x6e/0xd0
[ 89.857484] [<c1268ce7>] vfs_caches_init+0x77/0x90
[ 89.857484] [<c1237e8d>] start_kernel+0x25d/0x380
[ 89.857484] [<c1237092>] __init_begin+0x92/0xe0
[ 89.857484] [<ffffffff>] 0xffffffff
[ 89.886404] unreferenced object 0xf700d0e0 (size 8):
[ 89.888384] comm "swapper", pid 0, jiffies 4294892306
[ 89.890117] backtrace:
[ 89.890393] [<c0230695>] create_object+0x155/0x2c0
[ 89.890393] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
[ 89.890393] [<c022bb44>] __kmalloc_track_caller+0x234/0x2d0
[ 89.890393] [<c0200a95>] kstrdup+0x55/0xa0
[ 89.890393] [<c025dcf1>] alloc_vfsmnt+0xf1/0x170
[ 89.890393] [<c023b632>] vfs_kern_mount+0x52/0x230
[ 89.890393] [<c023ba2a>] kern_mount_data+0x1a/0x20
[ 89.890393] [<c126a03e>] bdev_cache_init+0x6e/0xd0
[ 89.890393] [<c1268ce7>] vfs_caches_init+0x77/0x90
[ 89.890393] [<c1237e8d>] start_kernel+0x25d/0x380
[ 89.890393] [<c1237092>] __init_begin+0x92/0xe0
[ 89.890393] [<ffffffff>] 0xffffffff
[ 89.926356] unreferenced object 0xf60f6080 (size 16):
[ 89.929082] comm "swapper", pid 1, jiffies 4294897223
[ 89.929480] backtrace:
[ 89.929480] [<c0230695>] create_object+0x155/0x2c0
[ 89.929480] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
[ 89.929480] [<c0228581>] kmem_cache_alloc+0x191/0x220
[ 89.929480] [<c03c9ecd>] reserve_range+0x52d/0x630
[ 89.929480] [<c03ca103>] reserve_resources_of_dev+0x133/0x150
[ 89.929480] [<c03ca12d>] system_pnp_probe+0xd/0x30
[ 89.929480] [<c03bb52d>] pnp_device_probe+0xed/0x1c0
[ 89.929480] [<c040d798>] really_probe+0x358/0x490
[ 89.929480] [<c040dada>] driver_probe_device+0xaa/0x150
[ 89.929480] [<c040dd69>] __driver_attach+0xb9/0x110
[ 89.929480] [<c040acf5>] bus_for_each_dev+0x65/0x90
[ 89.929480] [<c040ddde>] driver_attach+0x1e/0x30
[ 89.929480] [<c040baa2>] bus_add_driver+0x1a2/0x830
[ 89.929480] [<c040e568>] driver_register+0xc8/0x180
[ 89.929480] [<c03bb97c>] pnp_register_driver+0x1c/0x20
[ 89.929480] [<c1274c4d>] pnp_system_init+0xd/0x10
[ 89.978981] unreferenced object 0xf65205a0 (size 32):
[ 89.981599] comm "swapper", pid 1, jiffies 4294897223
[ 89.982969] backtrace:
[ 89.982969] [<c0230695>] create_object+0x155/0x2c0
[ 89.982969] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
[ 89.982969] [<c0228581>] kmem_cache_alloc+0x191/0x220
[ 89.982969] [<c016e29d>] __request_region+0x4cd/0x5d0
[ 89.982969] [<c03c9a6e>] reserve_range+0xce/0x630
[ 89.982969] [<c03ca103>] reserve_resources_of_dev+0x133/0x150
[ 89.982969] [<c03ca12d>] system_pnp_probe+0xd/0x30
[ 89.982969] [<c03bb52d>] pnp_device_probe+0xed/0x1c0
[ 89.982969] [<c040d798>] really_probe+0x358/0x490
[ 89.982969] [<c040dada>] driver_probe_device+0xaa/0x150
[ 89.982969] [<c040dd69>] __driver_attach+0xb9/0x110
[ 89.982969] [<c040acf5>] bus_for_each_dev+0x65/0x90
[ 89.982969] [<c040ddde>] driver_attach+0x1e/0x30
[ 89.982969] [<c040baa2>] bus_add_driver+0x1a2/0x830
[ 89.982969] [<c040e568>] driver_register+0xc8/0x180
[ 89.982969] [<c03bb97c>] pnp_register_driver+0x1c/0x20
[ 90.037062] unreferenced object 0xf6189ee0 (size 8):
[ 90.038484] comm "swapper", pid 1, jiffies 4294898432
[ 90.038484] backtrace:
[ 90.038484] [<c0230695>] create_object+0x155/0x2c0
[ 90.038484] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
[ 90.038484] [<c022a9ea>] __kmalloc+0x22a/0x2d0
[ 90.038484] [<c033fd06>] kvasprintf+0x36/0x80
[ 90.038484] [<c0332b63>] kobject_set_name_vargs+0x13/0x60
[ 90.038484] [<c0332ce1>] kobject_add_varg+0x21/0x70
[ 90.038484] [<c0332db0>] kobject_add+0x80/0xa0
[ 90.038484] [<c127ad05>] memmap_init+0xd5/0x160
[ 90.038484] [<c0101147>] do_one_initcall+0x47/0x2b0
[ 90.038484] [<c1237fda>] do_initcalls+0x2a/0x40
[ 90.038484] [<c123800c>] do_basic_setup+0x1c/0x20
[ 90.038484] [<c1238095>] kernel_init+0x55/0xd0
[ 90.038484] [<c01053a7>] kernel_thread_helper+0x7/0x10
[ 90.038484] [<ffffffff>] 0xffffffff
(...snipped...)
[ 94.387185] unreferenced object 0xf6cbec98 (size 56):
[ 94.389132] comm "rcS", pid 1332, jiffies 4294901842
[ 94.390892] backtrace:
[ 94.391173] [<c0230695>] create_object+0x155/0x2c0
[ 94.391173] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
[ 94.391173] [<c0228581>] kmem_cache_alloc+0x191/0x220
[ 94.391173] [<c02794fe>] alloc_buffer_head+0x1e/0xd0
[ 94.391173] [<c0272b9a>] alloc_page_buffers+0x3a/0x120
[ 94.391173] [<c0272f08>] grow_dev_page+0x168/0x2d0
[ 94.391173] [<c0273120>] grow_buffers+0xb0/0x140
[ 94.391173] [<c027329b>] __getblk_slow+0xeb/0x1d0
[ 94.391173] [<c0273d22>] __getblk+0x72/0x80
[ 94.391173] [<f895256e>] ext3_getblk+0x11e/0x3e0 [ext3]
[ 94.391173] [<f895989a>] ext3_find_entry+0x18a/0x6e0 [ext3]
[ 94.391173] [<f895a1dd>] ext3_lookup+0x5d/0x1c0 [ext3]
[ 94.391173] [<c0245ece>] real_lookup+0xbe/0x230
[ 94.391173] [<c02466af>] do_lookup+0x14f/0x240
[ 94.391173] [<c024742c>] __link_path_walk+0xc8c/0x17e0
[ 94.391173] [<c0247fc2>] path_walk+0x42/0xa0
How to analyze kmemleak message?
Where can I find documentation?
Regards.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to analyze kmemleak message?
2009-02-23 8:24 How to analyze kmemleak message? Tetsuo Handa
@ 2009-02-23 9:40 ` Pekka Enberg
2009-02-23 10:45 ` Catalin Marinas
0 siblings, 1 reply; 6+ messages in thread
From: Pekka Enberg @ 2009-02-23 9:40 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: linux-kernel, Catalin Marinas
(I'm cc'ing Catalin.)
On Mon, Feb 23, 2009 at 10:24 AM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> I got this message with linux-2.6.29-rc5-next-20090220 .
>
> [ 89.856902] unreferenced object 0xf7009180 (size 124):
> [ 89.857484] comm "swapper", pid 0, jiffies 4294892306
> [ 89.857484] backtrace:
> [ 89.857484] [<c0230695>] create_object+0x155/0x2c0
> [ 89.857484] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
> [ 89.857484] [<c0228581>] kmem_cache_alloc+0x191/0x220
> [ 89.857484] [<c025dc23>] alloc_vfsmnt+0x23/0x170
> [ 89.857484] [<c023b632>] vfs_kern_mount+0x52/0x230
> [ 89.857484] [<c023ba2a>] kern_mount_data+0x1a/0x20
> [ 89.857484] [<c126a03e>] bdev_cache_init+0x6e/0xd0
> [ 89.857484] [<c1268ce7>] vfs_caches_init+0x77/0x90
> [ 89.857484] [<c1237e8d>] start_kernel+0x25d/0x380
> [ 89.857484] [<c1237092>] __init_begin+0x92/0xe0
> [ 89.857484] [<ffffffff>] 0xffffffff
> [ 89.886404] unreferenced object 0xf700d0e0 (size 8):
> [ 89.888384] comm "swapper", pid 0, jiffies 4294892306
> [ 89.890117] backtrace:
> [ 89.890393] [<c0230695>] create_object+0x155/0x2c0
> [ 89.890393] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
> [ 89.890393] [<c022bb44>] __kmalloc_track_caller+0x234/0x2d0
> [ 89.890393] [<c0200a95>] kstrdup+0x55/0xa0
> [ 89.890393] [<c025dcf1>] alloc_vfsmnt+0xf1/0x170
> [ 89.890393] [<c023b632>] vfs_kern_mount+0x52/0x230
> [ 89.890393] [<c023ba2a>] kern_mount_data+0x1a/0x20
> [ 89.890393] [<c126a03e>] bdev_cache_init+0x6e/0xd0
> [ 89.890393] [<c1268ce7>] vfs_caches_init+0x77/0x90
> [ 89.890393] [<c1237e8d>] start_kernel+0x25d/0x380
> [ 89.890393] [<c1237092>] __init_begin+0x92/0xe0
> [ 89.890393] [<ffffffff>] 0xffffffff
> [ 89.926356] unreferenced object 0xf60f6080 (size 16):
> [ 89.929082] comm "swapper", pid 1, jiffies 4294897223
> [ 89.929480] backtrace:
> [ 89.929480] [<c0230695>] create_object+0x155/0x2c0
> [ 89.929480] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
> [ 89.929480] [<c0228581>] kmem_cache_alloc+0x191/0x220
> [ 89.929480] [<c03c9ecd>] reserve_range+0x52d/0x630
> [ 89.929480] [<c03ca103>] reserve_resources_of_dev+0x133/0x150
> [ 89.929480] [<c03ca12d>] system_pnp_probe+0xd/0x30
> [ 89.929480] [<c03bb52d>] pnp_device_probe+0xed/0x1c0
> [ 89.929480] [<c040d798>] really_probe+0x358/0x490
> [ 89.929480] [<c040dada>] driver_probe_device+0xaa/0x150
> [ 89.929480] [<c040dd69>] __driver_attach+0xb9/0x110
> [ 89.929480] [<c040acf5>] bus_for_each_dev+0x65/0x90
> [ 89.929480] [<c040ddde>] driver_attach+0x1e/0x30
> [ 89.929480] [<c040baa2>] bus_add_driver+0x1a2/0x830
> [ 89.929480] [<c040e568>] driver_register+0xc8/0x180
> [ 89.929480] [<c03bb97c>] pnp_register_driver+0x1c/0x20
> [ 89.929480] [<c1274c4d>] pnp_system_init+0xd/0x10
> [ 89.978981] unreferenced object 0xf65205a0 (size 32):
> [ 89.981599] comm "swapper", pid 1, jiffies 4294897223
> [ 89.982969] backtrace:
> [ 89.982969] [<c0230695>] create_object+0x155/0x2c0
> [ 89.982969] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
> [ 89.982969] [<c0228581>] kmem_cache_alloc+0x191/0x220
> [ 89.982969] [<c016e29d>] __request_region+0x4cd/0x5d0
> [ 89.982969] [<c03c9a6e>] reserve_range+0xce/0x630
> [ 89.982969] [<c03ca103>] reserve_resources_of_dev+0x133/0x150
> [ 89.982969] [<c03ca12d>] system_pnp_probe+0xd/0x30
> [ 89.982969] [<c03bb52d>] pnp_device_probe+0xed/0x1c0
> [ 89.982969] [<c040d798>] really_probe+0x358/0x490
> [ 89.982969] [<c040dada>] driver_probe_device+0xaa/0x150
> [ 89.982969] [<c040dd69>] __driver_attach+0xb9/0x110
> [ 89.982969] [<c040acf5>] bus_for_each_dev+0x65/0x90
> [ 89.982969] [<c040ddde>] driver_attach+0x1e/0x30
> [ 89.982969] [<c040baa2>] bus_add_driver+0x1a2/0x830
> [ 89.982969] [<c040e568>] driver_register+0xc8/0x180
> [ 89.982969] [<c03bb97c>] pnp_register_driver+0x1c/0x20
> [ 90.037062] unreferenced object 0xf6189ee0 (size 8):
> [ 90.038484] comm "swapper", pid 1, jiffies 4294898432
> [ 90.038484] backtrace:
> [ 90.038484] [<c0230695>] create_object+0x155/0x2c0
> [ 90.038484] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
> [ 90.038484] [<c022a9ea>] __kmalloc+0x22a/0x2d0
> [ 90.038484] [<c033fd06>] kvasprintf+0x36/0x80
> [ 90.038484] [<c0332b63>] kobject_set_name_vargs+0x13/0x60
> [ 90.038484] [<c0332ce1>] kobject_add_varg+0x21/0x70
> [ 90.038484] [<c0332db0>] kobject_add+0x80/0xa0
> [ 90.038484] [<c127ad05>] memmap_init+0xd5/0x160
> [ 90.038484] [<c0101147>] do_one_initcall+0x47/0x2b0
> [ 90.038484] [<c1237fda>] do_initcalls+0x2a/0x40
> [ 90.038484] [<c123800c>] do_basic_setup+0x1c/0x20
> [ 90.038484] [<c1238095>] kernel_init+0x55/0xd0
> [ 90.038484] [<c01053a7>] kernel_thread_helper+0x7/0x10
> [ 90.038484] [<ffffffff>] 0xffffffff
> (...snipped...)
> [ 94.387185] unreferenced object 0xf6cbec98 (size 56):
> [ 94.389132] comm "rcS", pid 1332, jiffies 4294901842
> [ 94.390892] backtrace:
> [ 94.391173] [<c0230695>] create_object+0x155/0x2c0
> [ 94.391173] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
> [ 94.391173] [<c0228581>] kmem_cache_alloc+0x191/0x220
> [ 94.391173] [<c02794fe>] alloc_buffer_head+0x1e/0xd0
> [ 94.391173] [<c0272b9a>] alloc_page_buffers+0x3a/0x120
> [ 94.391173] [<c0272f08>] grow_dev_page+0x168/0x2d0
> [ 94.391173] [<c0273120>] grow_buffers+0xb0/0x140
> [ 94.391173] [<c027329b>] __getblk_slow+0xeb/0x1d0
> [ 94.391173] [<c0273d22>] __getblk+0x72/0x80
> [ 94.391173] [<f895256e>] ext3_getblk+0x11e/0x3e0 [ext3]
> [ 94.391173] [<f895989a>] ext3_find_entry+0x18a/0x6e0 [ext3]
> [ 94.391173] [<f895a1dd>] ext3_lookup+0x5d/0x1c0 [ext3]
> [ 94.391173] [<c0245ece>] real_lookup+0xbe/0x230
> [ 94.391173] [<c02466af>] do_lookup+0x14f/0x240
> [ 94.391173] [<c024742c>] __link_path_walk+0xc8c/0x17e0
> [ 94.391173] [<c0247fc2>] path_walk+0x42/0xa0
>
> How to analyze kmemleak message?
The stack traces refer to the call-site that allocated an unfree'd
object that is no longer being referenced by anyone. For example, the
first stack trace claims that vfs_kern_mount() allocated a struct
vfsmount that was never free'd.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to analyze kmemleak message?
2009-02-23 9:40 ` Pekka Enberg
@ 2009-02-23 10:45 ` Catalin Marinas
2009-02-23 11:29 ` Tetsuo Handa
0 siblings, 1 reply; 6+ messages in thread
From: Catalin Marinas @ 2009-02-23 10:45 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Tetsuo Handa, linux-kernel
On Mon, 2009-02-23 at 11:40 +0200, Pekka Enberg wrote:
> On Mon, Feb 23, 2009 at 10:24 AM, Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
> > I got this message with linux-2.6.29-rc5-next-20090220 .
As Pekka said, they refer to the place where the object was allocated.
This object can no longer be found to be referred by other objects or
from the data section, hence it is assumed to be a leak (it could, as
well, be a false positive, transient or not). Basically, you need check
where the pointer returned by kmalloc/kmem_cache_alloc etc. should be
stored and whether it can still be referred from that place (or a
different one) later.
Kmemleak tries to avoid the reporting of transient leaks by only
reporting objects with a life time of more than 5 seconds. To make sure
the reports you got aren't transient leaks, you can read
the /sys/kernel/debug/kmemleak file a few times to see whether they
disappear.
There is a Documentation/kmemleak.txt file where you may find some
useful information.
Please note that the leaks are always reported in the order they were
allocated. You may find that some early leak triggers subsequent leaks
hence only one may need to be solved (this is because a leaked object
isn't scanned by kmemleak though it may contain pointers to other
objects - e.g. the alloc_vfsmnt leak below).
> > [ 89.856902] unreferenced object 0xf7009180 (size 124):
> > [ 89.857484] comm "swapper", pid 0, jiffies 4294892306
> > [ 89.857484] backtrace:
> > [ 89.857484] [<c0230695>] create_object+0x155/0x2c0
> > [ 89.857484] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
> > [ 89.857484] [<c0228581>] kmem_cache_alloc+0x191/0x220
> > [ 89.857484] [<c025dc23>] alloc_vfsmnt+0x23/0x170
> > [ 89.857484] [<c023b632>] vfs_kern_mount+0x52/0x230
> > [ 89.857484] [<c023ba2a>] kern_mount_data+0x1a/0x20
> > [ 89.857484] [<c126a03e>] bdev_cache_init+0x6e/0xd0
> > [ 89.857484] [<c1268ce7>] vfs_caches_init+0x77/0x90
> > [ 89.857484] [<c1237e8d>] start_kernel+0x25d/0x380
> > [ 89.857484] [<c1237092>] __init_begin+0x92/0xe0
> > [ 89.857484] [<ffffffff>] 0xffffffff
> > [ 89.886404] unreferenced object 0xf700d0e0 (size 8):
> > [ 89.888384] comm "swapper", pid 0, jiffies 4294892306
> > [ 89.890117] backtrace:
> > [ 89.890393] [<c0230695>] create_object+0x155/0x2c0
> > [ 89.890393] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
> > [ 89.890393] [<c022bb44>] __kmalloc_track_caller+0x234/0x2d0
> > [ 89.890393] [<c0200a95>] kstrdup+0x55/0xa0
> > [ 89.890393] [<c025dcf1>] alloc_vfsmnt+0xf1/0x170
> > [ 89.890393] [<c023b632>] vfs_kern_mount+0x52/0x230
> > [ 89.890393] [<c023ba2a>] kern_mount_data+0x1a/0x20
> > [ 89.890393] [<c126a03e>] bdev_cache_init+0x6e/0xd0
> > [ 89.890393] [<c1268ce7>] vfs_caches_init+0x77/0x90
> > [ 89.890393] [<c1237e8d>] start_kernel+0x25d/0x380
> > [ 89.890393] [<c1237092>] __init_begin+0x92/0xe0
> > [ 89.890393] [<ffffffff>] 0xffffffff
These are known to be leaks and I posted a patch some time ago:
http://lkml.org/lkml/2009/1/14/175
> > [ 89.926356] unreferenced object 0xf60f6080 (size 16):
> > [ 89.929082] comm "swapper", pid 1, jiffies 4294897223
> > [ 89.929480] backtrace:
> > [ 89.929480] [<c0230695>] create_object+0x155/0x2c0
> > [ 89.929480] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
> > [ 89.929480] [<c0228581>] kmem_cache_alloc+0x191/0x220
> > [ 89.929480] [<c03c9ecd>] reserve_range+0x52d/0x630
> > [ 89.929480] [<c03ca103>] reserve_resources_of_dev+0x133/0x150
> > [ 89.929480] [<c03ca12d>] system_pnp_probe+0xd/0x30
> > [ 89.929480] [<c03bb52d>] pnp_device_probe+0xed/0x1c0
> > [ 89.929480] [<c040d798>] really_probe+0x358/0x490
> > [ 89.929480] [<c040dada>] driver_probe_device+0xaa/0x150
> > [ 89.929480] [<c040dd69>] __driver_attach+0xb9/0x110
> > [ 89.929480] [<c040acf5>] bus_for_each_dev+0x65/0x90
> > [ 89.929480] [<c040ddde>] driver_attach+0x1e/0x30
> > [ 89.929480] [<c040baa2>] bus_add_driver+0x1a2/0x830
> > [ 89.929480] [<c040e568>] driver_register+0xc8/0x180
> > [ 89.929480] [<c03bb97c>] pnp_register_driver+0x1c/0x20
> > [ 89.929480] [<c1274c4d>] pnp_system_init+0xd/0x10
Here, the regionid allocated in reserve_range() is reported as a leak.
> > [ 89.978981] unreferenced object 0xf65205a0 (size 32):
> > [ 89.981599] comm "swapper", pid 1, jiffies 4294897223
> > [ 89.982969] backtrace:
> > [ 89.982969] [<c0230695>] create_object+0x155/0x2c0
> > [ 89.982969] [<c0230dcb>] kmemleak_alloc+0x10b/0x1b0
> > [ 89.982969] [<c0228581>] kmem_cache_alloc+0x191/0x220
> > [ 89.982969] [<c016e29d>] __request_region+0x4cd/0x5d0
> > [ 89.982969] [<c03c9a6e>] reserve_range+0xce/0x630
> > [ 89.982969] [<c03ca103>] reserve_resources_of_dev+0x133/0x150
> > [ 89.982969] [<c03ca12d>] system_pnp_probe+0xd/0x30
> > [ 89.982969] [<c03bb52d>] pnp_device_probe+0xed/0x1c0
> > [ 89.982969] [<c040d798>] really_probe+0x358/0x490
> > [ 89.982969] [<c040dada>] driver_probe_device+0xaa/0x150
> > [ 89.982969] [<c040dd69>] __driver_attach+0xb9/0x110
> > [ 89.982969] [<c040acf5>] bus_for_each_dev+0x65/0x90
> > [ 89.982969] [<c040ddde>] driver_attach+0x1e/0x30
> > [ 89.982969] [<c040baa2>] bus_add_driver+0x1a2/0x830
> > [ 89.982969] [<c040e568>] driver_register+0xc8/0x180
> > [ 89.982969] [<c03bb97c>] pnp_register_driver+0x1c/0x20
The resource structure allocated in __request_region() cannot be found
to be referred either. It seems that the previous regionid leak may be
just a side effect of the above leak as the resource structure was
supposed to reference the regionid (via the name field).
For the above regionid and this one, you can dump the objects via
the /dev/kmem and get the name of the resource. You could also look
in /proc/iomem or /proc/ioports but if that's a real leak the resource
name shouldn't be there (but first check the reported leaks again via
the /sys/kernel/debug/kmemleak file).
Please keep me in the loop if you find any real leaks or they are just
false positives.
Thanks.
--
Catalin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to analyze kmemleak message?
2009-02-23 10:45 ` Catalin Marinas
@ 2009-02-23 11:29 ` Tetsuo Handa
2009-02-23 12:20 ` Catalin Marinas
0 siblings, 1 reply; 6+ messages in thread
From: Tetsuo Handa @ 2009-02-23 11:29 UTC (permalink / raw)
To: catalin.marinas, penberg; +Cc: linux-kernel
Hello.
Thank you for explanation.
Catalin Marinas wrote:
> As Pekka said, they refer to the place where the object was allocated.
OK. The trace shows where that memory was allocated.
> This object can no longer be found to be referred by other objects or
> from the data section, hence it is assumed to be a leak (it could, as
> well, be a false positive, transient or not).
Kmemleak scans all data section for addresses returned by kmalloc() etc.
void *p1;
void foo(void)
{
void *p2 = kmalloc(1, GFP_KERNEL);
p1 = kmalloc(1, GFP_KERNEL);
}
"p1" will be reported by default.
To report "p2", we need to write "stack=on" to /sys/kernel/debug/kmemleak .
Is this correct?
> Basically, you need check
> where the pointer returned by kmalloc/kmem_cache_alloc etc. should be
> stored and whether it can still be referred from that place (or a
> different one) later.
>
> Kmemleak tries to avoid the reporting of transient leaks by only
> reporting objects with a life time of more than 5 seconds.
kjournald's commit interval (default to 5 sec?) + a few seconds
might be better. (No reason. Just my feeling.)
> To make sure
> the reports you got aren't transient leaks, you can read
> the /sys/kernel/debug/kmemleak file a few times to see whether they
> disappear.
Well, I couldn't check /sys/kernel/debug/kmemleak etc. because
I couldn't reach login prompt.
> There is a Documentation/kmemleak.txt file where you may find some
> useful information.
I see.
I have a question. My module uses kmalloc(PATH_MAX, GFP_KERNEL) which
won't be released by kfree(). I count up how many bytes are allocated but
I don't want kmemleak to report such memory as memory leaks.
Can I do so by
void bar(void)
{
static void *p;
if (!p) {
p = kmalloc(PATH_MAX, GFP_KERNEL);
kmemleak_not_leak(p);
}
...
}
(or kmemleak_ignore() (which one to use and how to use))?
Regards.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to analyze kmemleak message?
2009-02-23 11:29 ` Tetsuo Handa
@ 2009-02-23 12:20 ` Catalin Marinas
2009-02-23 12:59 ` Tetsuo Handa
0 siblings, 1 reply; 6+ messages in thread
From: Catalin Marinas @ 2009-02-23 12:20 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: penberg, linux-kernel
On Mon, 2009-02-23 at 20:29 +0900, Tetsuo Handa wrote:
> Catalin Marinas wrote:
> > This object can no longer be found to be referred by other objects or
> > from the data section, hence it is assumed to be a leak (it could, as
> > well, be a false positive, transient or not).
> Kmemleak scans all data section for addresses returned by kmalloc() etc.
>
> void *p1;
>
> void foo(void)
> {
> void *p2 = kmalloc(1, GFP_KERNEL);
> p1 = kmalloc(1, GFP_KERNEL);
> }
>
> "p1" will be reported by default.
p1 won't be reported as a leak because it is a global variable and the
data section is scanned.
> To report "p2", we need to write "stack=on" to /sys/kernel/debug/kmemleak .
It's the opposite - p2 will be reported as leak by default (stack=off)
unless you enable the stack scanning (stack=on). Note that in the above
case, even if you scan the stacks, once foo() finished the data on the
stack may be overridden by other function calls and p2 will be reported
as a leak.
> > Basically, you need check
> > where the pointer returned by kmalloc/kmem_cache_alloc etc. should be
> > stored and whether it can still be referred from that place (or a
> > different one) later.
> >
> > Kmemleak tries to avoid the reporting of transient leaks by only
> > reporting objects with a life time of more than 5 seconds.
> kjournald's commit interval (default to 5 sec?) + a few seconds
> might be better. (No reason. Just my feeling.)
I don't think it will make any difference but I may try to increase this
if I get too many transient leaks reported.
> I have a question. My module uses kmalloc(PATH_MAX, GFP_KERNEL) which
> won't be released by kfree(). I count up how many bytes are allocated but
> I don't want kmemleak to report such memory as memory leaks.
> Can I do so by
>
> void bar(void)
> {
> static void *p;
> if (!p) {
> p = kmalloc(PATH_MAX, GFP_KERNEL);
> kmemleak_not_leak(p);
> }
> ...
> }
>
> (or kmemleak_ignore() (which one to use and how to use))?
I don't think you need to do anything here. Since p is a static local
variable, isn't it placed in a data section somewhere (and automatically
scanned by kmemleak)?
FYI, kmemleak_ignore() is meant for objects which aren't leaks and which
don't need to be scanned for pointers to other objects (i.e. the code
sections in a module). kmemleak_not_leak() is meant for objects which
are reported as leaks but are known not to be (i.e. the pointer is
stored in a place that kmemleak doesn't scan or the pointer value is
modified before storing or reading) and they should be scanned for
pointers to other objects.
--
Catalin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to analyze kmemleak message?
2009-02-23 12:20 ` Catalin Marinas
@ 2009-02-23 12:59 ` Tetsuo Handa
0 siblings, 0 replies; 6+ messages in thread
From: Tetsuo Handa @ 2009-02-23 12:59 UTC (permalink / raw)
To: catalin.marinas; +Cc: penberg, linux-kernel
Hello.
Catalin Marinas wrote:
> On Mon, 2009-02-23 at 20:29 +0900, Tetsuo Handa wrote:
> > void *p1;
> >
> > void foo(void)
> > {
> > void *p2 = kmalloc(1, GFP_KERNEL);
> > p1 = kmalloc(1, GFP_KERNEL);
> > }
> >
> > "p1" will be reported by default.
>
> p1 won't be reported as a leak because it is a global variable and the
> data section is scanned.
>
I see.
> > To report "p2", we need to write "stack=on" to /sys/kernel/debug/kmemleak .
>
> It's the opposite - p2 will be reported as leak by default (stack=off)
> unless you enable the stack scanning (stack=on).
>
I see.
> I don't think you need to do anything here. Since p is a static local
> variable, isn't it placed in a data section somewhere (and automatically
> scanned by kmemleak)?
>
I see.
After all, I have nothing to modify for kmemleak. All I need to do is
"Just turn on kmemleak and see if functions in my module are reported or not".
Thank you.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-02-23 13:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-23 8:24 How to analyze kmemleak message? Tetsuo Handa
2009-02-23 9:40 ` Pekka Enberg
2009-02-23 10:45 ` Catalin Marinas
2009-02-23 11:29 ` Tetsuo Handa
2009-02-23 12:20 ` Catalin Marinas
2009-02-23 12:59 ` Tetsuo Handa
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).