| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 20 Oct 2009 11:58:39 +0200
From: Zdenek Kabelac <zdenek.kabelac@...il.com>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Li Zefan <lizf@...fujitsu.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: Leaks in trace reported by kmemleak
2009/10/19 Catalin Marinas <catalin.marinas@....com>:
> On Mon, 2009-10-19 at 13:00 +0100, Catalin Marinas wrote:
>> On Mon, 2009-10-19 at 11:15 +0200, Zdenek Kabelac wrote:
>> > What is however interesting is the false positive leak for
>> > dma_debug_init(). Which is sometimes listed and sometimes not - the
>> > memory is allocated just once in the code during boot, so it's strange
>> > that pointers to that area are sometimes out of kmemleak scan.
>>
>> A workaround I had in the past was to not report an object unless it was
>> found as a leak in two consecutive scans. I should probably reinstate
>> this feature (could be optimised to use a second prio_tree containing
>> only objects found as leaks).
>
> OK, I re-added a form of this to the kmemleak.git tree and simplified
> the scanning logic (meant initially to reduce the false positives). Now,
> for an object to be reported, it needs to be found as leak during two
> consecutive scans (this works around pointer moving from a structure to
> a different one which was already scanned).
>
> If you have time, could you please give it a try and see whether you
> still get transient false positives?
>
> As for the patch showing where an object is referred from, I think it's
> still useful for debugging possible false negatives, so I'll leave it
> in.
>
> Thanks.
I've tested your git with updates - and here is my experience:
I'm still able to get FP leaks printed even with the print of
more-then-once appearanc.
i.e. here is output of dump=
kmemleak: Object 0xffff8801390fd300 (size 192):
kmemleak: comm "swapper", pid 1, jiffies 4294877823
kmemleak: min_count = 1
kmemleak: count = 0
kmemleak: flags = 0xb
kmemleak: backtrace:
[<ffffffff8140e986>] kmemleak_alloc+0x26/0x50
[<ffffffff811269f1>] kmem_cache_alloc_notrace+0xc1/0x140
[<ffffffff8127243a>] dma_debug_init+0x23a/0x3a0
[<ffffffff81864a37>] pci_iommu_init+0xe/0x28
[<ffffffff8100904c>] do_one_initcall+0x3c/0x1d0
[<ffffffff8185f4e6>] kernel_init+0x150/0x1a6
[<ffffffff8100d21a>] child_rip+0xa/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
i think it would be useful to print count of leak appearance - i.e.
leak was seen during XX scans.
Also jiffies might be eventually more readable via data/time - but
this can be preprocessed via script.
So it still looks like some memory areas are missing in scan.
I think new interesting 'probably real leak is being printed from
cpufreq during pm-suspend - it seems to be repeatable.
unreferenced object 0xffff880139bdfc10 (size 8):
comm "swapper", pid 1, jiffies 4294878042
hex dump (first 8 bytes):
63 70 75 66 72 65 71 00 cpufreq.
backtrace:
[<ffffffff8140e986>] kmemleak_alloc+0x26/0x50
[<ffffffff81127953>] __kmalloc_track_caller+0x143/0x230
[<ffffffff81104395>] kstrdup+0x45/0x80
[<ffffffff8119e2cc>] sysfs_new_dirent+0x10c/0x120
[<ffffffff8119f132>] create_dir+0x42/0xb0
[<ffffffff8119f1d9>] sysfs_create_dir+0x39/0x50
[<ffffffff8126048b>] kobject_add_internal+0x11b/0x210
[<ffffffff812606a8>] kobject_add_varg+0x38/0x60
[<ffffffff81260723>] kobject_init_and_add+0x53/0x70
[<ffffffff81373552>] cpufreq_add_dev_interface+0x42/0x220
[<ffffffff81373cee>] cpufreq_add_dev+0x27e/0x410
[<ffffffff8130e636>] sysdev_driver_register+0xa6/0x130
[<ffffffff81371d38>] cpufreq_register_driver+0x88/0x160
[<ffffffff81867c8c>] acpi_cpufreq_init+0x91/0xc7
[<ffffffff8100904c>] do_one_initcall+0x3c/0x1d0
[<ffffffff8185f4e6>] kernel_init+0x150/0x1a6
unreferenced object 0xffff8801350a5410 (size 80):
comm "pm-suspend", pid 2841, jiffies 4296695092
hex dump (first 32 bytes):
04 00 00 00 00 00 00 00 00 50 0a 35 01 88 ff ff .........P.5....
00 00 00 00 00 00 00 00 28 58 20 3a 01 88 ff ff ........(X :....
backtrace:
[<ffffffff8140e986>] kmemleak_alloc+0x26/0x50
[<ffffffff81126c73>] kmem_cache_alloc+0x133/0x1c0
[<ffffffff8119e201>] sysfs_new_dirent+0x41/0x120
[<ffffffff8119f132>] create_dir+0x42/0xb0
[<ffffffff8119f20b>] sysfs_create_subdir+0x1b/0x20
[<ffffffff811a0508>] internal_create_group+0x58/0x1a0
[<ffffffff811a0683>] sysfs_create_group+0x13/0x20
[<ffffffff8137477a>] cpufreq_stat_notifier_policy+0xda/0x2b0
[<ffffffff81424788>] notifier_call_chain+0x78/0xb0
[<ffffffff8107f190>] __blocking_notifier_call_chain+0x60/0x90
[<ffffffff8107f1d6>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff81373329>] __cpufreq_set_policy+0xc9/0x190
[<ffffffff813736e3>] cpufreq_add_dev_interface+0x1d3/0x220
[<ffffffff81373cee>] cpufreq_add_dev+0x27e/0x410
[<ffffffff8141d244>] cpufreq_cpu_callback+0x71/0x7e
[<ffffffff81424788>] notifier_call_chain+0x78/0xb0
.....
I've made also test with removal of as much modules as possible
(though for some reason some of them were kept in memory, because I
couldn't decrease module count to 0 - while nearly every userland task
was killed except for bash and mingetty
ipt_MASQUERADE 1823 1
iptable_nat 4228 1
nf_nat 18462 2 ipt_MASQUERADE,iptable_nat
nf_conntrack_ipv4 12687 3 iptable_nat,nf_nat
nf_defrag_ipv4 1353 1 nf_conntrack_ipv4
nf_conntrack 72037 4
ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4
ip_tables 16520 1 iptable_nat
x_tables 20541 3 ipt_MASQUERADE,iptable_nat,ip_tables
sunrpc 221415 1
ipv6 292258 10
binfmt_misc 7686 1
usbcore 168536 1
This left few other leaks - however because trace after module removal
is meaningless it's hard to say from where the leak comes from. Well -
how about adding new command "echo resolve >debug/kmemleak". This
would resolve all backtraces - it would surely eat 'some' memory - but
it would give the usable trace for removed modules. I think lots' of
stack traces could eventually use some sort of heap - to avoid
duplicate resolving of same stack and keeping same strings in memory.
Anyway here are few leaks from i915 -
unreferenced object 0xffff8800bf15fba0 (size 544):
comm "X", pid 2014, jiffies 4299475327
hex dump (first 32 bytes):
ff ff ff ff ff ff ff ff 40 db aa ba 00 88 ff ff ........@.......
00 df aa ba 00 88 ff ff c0 d0 aa ba 00 88 ff ff ................
backtrace:
[<ffffffff8140e986>] kmemleak_alloc+0x26/0x50
[<ffffffff81126c73>] kmem_cache_alloc+0x133/0x1c0
[<ffffffff8125f43f>] idr_pre_get+0x5f/0x90
[<ffffffffa03374cd>] drm_gem_handle_create+0x3d/0xb0 [drm]
[<ffffffffa0379815>] i915_gem_create_ioctl+0x65/0xc0 [i915]
[<ffffffffa0335f76>] drm_ioctl+0x176/0x390 [drm]
[<ffffffff81143b9c>] vfs_ioctl+0x7c/0xa0
[<ffffffff81143ce4>] do_vfs_ioctl+0x84/0x590
[<ffffffff81144271>] sys_ioctl+0x81/0xa0
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
Those are present also after i915 removal:
unreferenced object 0xffff880132f31760 (size 544):
comm "X", pid 2014, jiffies 4294899254
hex dump (first 32 bytes):
ff ff ff df fe dd f5 9a 40 4e 34 30 01 88 ff ff ........@.......
80 41 34 30 01 88 ff ff c0 46 34 30 01 88 ff ff .A40.....F40....
backtrace:
[<ffffffff8140e986>] kmemleak_alloc+0x26/0x50
[<ffffffff81126c73>] kmem_cache_alloc+0x133/0x1c0
[<ffffffff8125f43f>] idr_pre_get+0x5f/0x90
[<ffffffffa03374cd>] 0xffffffffa03374cd
[<ffffffffa0379815>] 0xffffffffa0379815
[<ffffffffa0335f76>] 0xffffffffa0335f76
[<ffffffff81143b9c>] vfs_ioctl+0x7c/0xa0
[<ffffffff81143ce4>] do_vfs_ioctl+0x84/0x590
[<ffffffff81144271>] sys_ioctl+0x81/0xa0
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
And one from iwl3945:
unreferenced object 0xffff8801280f4900 (size 256):
comm "events/0", pid 9, jiffies 4301085444
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8140e986>] kmemleak_alloc+0x26/0x50
[<ffffffff81126c73>] kmem_cache_alloc+0x133/0x1c0
[<ffffffff813891ea>] __alloc_skb+0x4a/0x180
[<ffffffff8140b292>] wireless_send_event+0x1f2/0x410
[<ffffffffa00fdeec>] ___cfg80211_scan_done+0xcc/0xf0 [cfg80211]
[<ffffffffa00fdf3b>] __cfg80211_scan_done+0x2b/0x50 [cfg80211]
[<ffffffff81073ada>] worker_thread+0x21a/0x400
[<ffffffff810794a6>] kthread+0x96/0xa0
[<ffffffff8100d21a>] child_rip+0xa/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
after removal of iwl3945:
unreferenced object 0xffff8801280f4900 (size 256):
comm "events/0", pid 9, jiffies 4301085444
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8140e986>] kmemleak_alloc+0x26/0x50
[<ffffffff81126c73>] kmem_cache_alloc+0x133/0x1c0
[<ffffffff813891ea>] __alloc_skb+0x4a/0x180
[<ffffffff8140b292>] wireless_send_event+0x1f2/0x410
[<ffffffffa00fdeec>] 0xffffffffa00fdeec
[<ffffffffa00fdf3b>] 0xffffffffa00fdf3b
[<ffffffff81073ada>] worker_thread+0x21a/0x400
[<ffffffff810794a6>] kthread+0x96/0xa0
[<ffffffff8100d21a>] child_rip+0xa/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
And could be matched because of idr_pre_get() vfs_ioctl() usage pattern
I'll try to look later in the code myself.
Zdenek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists