If I suspend2ram my ThinkPad T400 (sync; echo mem > /sys/power/state) and wake it up I get this kmemleak : unreferenced object 0xf5dee180 (size 192): comm "bash", pid 8961, jiffies 8253287 (age 3162.370s) hex dump (first 32 bytes): 61 09 00 00 00 00 00 00 b8 88 00 00 00 00 00 00 a............... 0a 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 ................ backtrace: [<c122caed>] kmemleak_alloc+0x3d/0x60 [<c109c852>] __kmalloc+0xf2/0x120 [<f80968ec>] acpi_processor_register_performance+0x264/0x3d5 [processor] [<f993d779>] acpi_cpufreq_cpu_init+0xb9/0x5a0 [acpi_cpufreq] [<c11c07cc>] cpufreq_add_dev+0x1ac/0x710 [<c1239415>] cpufreq_cpu_callback+0x45/0x67 [<c104d10d>] notifier_call_chain+0x2d/0x60 [<c104d24a>] raw_notifier_call_chain+0x1a/0x20 [<c123822c>] _cpu_up+0x107/0x10d [<c122bf83>] enable_nonboot_cpus+0x83/0xb0 [<c1060fa0>] suspend_devices_and_enter+0xf0/0x1a0 [<c1061122>] enter_state+0xd2/0xf0 [<c1060910>] state_store+0x80/0xc0 [<c1122e34>] kobj_attr_store+0x24/0x30 [<c10e771d>] sysfs_write_file+0x9d/0x100 [<c10a2b7c>] vfs_write+0x9c/0x180
is this a regression? please attach the full dmesg output after resuming from S3.
Created attachment 26387 [details] dmesg (In reply to comment #1) > is this a regression? I'm unsure > please attach the full dmesg output after resuming from S3.
Created attachment 26388 [details] cp /sys/kernel/debug/kmemleak kmemleak
Kernel 2.6.33.4 does not show this beahviour, I will attached dmesg and kmemleak of v2.6.34-rc7-154-g18e41da
Created attachment 26398 [details] kmemleak
Created attachment 26399 [details] dmesg
I forgot to mention that the kmemleak seems to happen only if I have an Konsole window open (KDe 4.4) before suspend2ram.
does the problem still exist in 2.6.35-rc?
(In reply to comment #8) > does the problem still exist in 2.6.35-rc? No, the bash entry is gone. FWIW I've currently these : tfoerste@n22 ~ $ perl -wane '$h{$F[1]}++ if m/^ comm/; END { foreach $k (sort keys %h) { print $k, $h{$k}, "\n"; } }' < /sys/kernel/debug/kmemleak "firefox",1 "glschool",15 "modprobe",2 "mount",1 "pipewalker",9 "pm-suspend",7 "pulsar",3 "swapper",33
the "modprobe" one still exists, and it's acpi cpu driver related, right?
Created attachment 26907 [details] patch: kmemleak fixup please try this patch and see if there is any change. please attach the content of the kmemleak file both w/ and w/o this patch.
Created attachment 26913 [details] kmemleak w/o patch
Created attachment 26914 [details] kmemleak w/ patch
Fengguang, do you have any ideas on this problem?
ping fengguang. Toralf, does the problem still exist in the latest upstream kernel?
Didn't observed this since 2.6.35.4
please re-open the bug if the problem can be reproduced in the latest kernel.
Created attachment 32362 [details] /sys/kernel/debug/kmemleak Here are some more kmemleaks with 2.6.35.5 : tfoerste@n22 ~ $ perl -wane '$h{$F[1]}++ if m/^ comm/ } END { foreach $k (sort keys %h) { print $k, $h{$k}, "\n"; }' /sys/kernel/debug/kmemleak "async/23",2 "async/27",2 "default.sh",2 "modprobe",1 "softirq",3 The kernel was patched with this code snippet to remove few kmemleaks from i915: tfoerste@n22 ~ $ cat devel/i915_kmemleak.patch diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 510bc87..b5a5168 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -335,6 +335,7 @@ static void __exit drm_core_exit(void) unregister_chrdev(DRM_MAJOR, "drm"); + idr_remove_all(&drm_minors_idr); idr_destroy(&drm_minors_idr); } diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 8601b72..4f1b867 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -429,6 +429,7 @@ drm_gem_release(struct drm_device *dev, struct drm_file *file_private) idr_for_each(&file_private->object_idr, &drm_gem_object_release_handle, NULL); + idr_remove_all(&file_private->object_idr); idr_destroy(&file_private->object_idr); }
*** Bug 16489 has been marked as a duplicate of this bug. ***
FWIW w/ kernel v2.6.36-rc7-69-g6b0cd00 kmemleaks now reports : foerste@n22 ~ $ cat /sys/kernel/debug/kmemleak unreferenced object 0xf6450e80 (size 64): comm "modprobe", pid 1066, jiffies 4294677317 (age 19290.453s) hex dump (first 32 bytes): 00 00 00 00 e8 a2 24 00 01 00 00 00 00 9f 24 00 ......$.......$. 02 00 00 00 00 6a 18 00 03 00 00 00 00 35 0c 00 .....j.......5.. backtrace: [<c123ba97>] kmemleak_alloc+0x27/0x50 [<c109f96f>] __kmalloc+0xcf/0x110 [<f9da97ee>] acpi_cpufreq_cpu_init+0x1ee/0x4e4 [acpi_cpufreq] [<c11cd8d2>] cpufreq_add_dev+0x142/0x3a0 [<c11920b7>] sysdev_driver_register+0x97/0x110 [<c11cce56>] cpufreq_register_driver+0x86/0x140 [<f9dad080>] 0xf9dad080 [<c1001130>] do_one_initcall+0x30/0x160 [<c10626e9>] sys_init_module+0x99/0x1e0 [<c1002d97>] sysenter_do_call+0x12/0x26 [<ffffffff>] 0xffffffff
Created attachment 33172 [details] patch: fix a kmemleak in acpi-freq driver would you please try this patch and see if it helps?
(In reply to comment #21) > Created an attachment (id=33172) [details] > patch: fix a kmemleak in acpi-freq driver > > would you please try this patch and see if it helps? It helped :-)
good to know. Patch is sent out, https://patchwork.kernel.org/patch/246641/
shipped in 2.6.37-rc1, and requested for .stable closed. commit dab5fff14df2cd16eb1ad4c02e83915e1063fece Author: Zhang Rui <rui.zhang@intel.com> Date: Tue Oct 12 09:09:37 2010 +0800 acpi-cpufreq: fix a memleak when unloading driver