On 12/07/06, Michal Piotrowski <[email protected]> wrote:
Here is a slabinfo from current 2.6.18-rc1-git4 and 2.6.18-rc1 +
kmemleak http://www.stardust.webpages.pl/files/o_bugs/kml/slab.txt
Thanks. Does it make any difference if you enable
CONFIG_DEBUG_MEMLEAK_TASK_STACKS? Also, if you save the memleak file
periodically, do any of the context_struct_to_string reports disappear
(I can investigate this if you upload a few ml60.txt, mk61.txt etc.)?
I haven't seen that before
orphan pointer 0xf1283e34 (size 224):
c01735c2: <kmem_cache_alloc>
fdc8c5cf: <ip_conntrack_alloc>
fdc8c6a3: <init_conntrack>
fdc8c894: <ip_conntrack_in>
fdc8b652: <ip_conntrack_local>
c02c15bf: <nf_iterate>
c02c1630: <nf_hook_slow>
c02e127e: <raw_send_hdrinc>
This looks like a false positive as the conntrack pointer is lost in
init_conntrack and only a pointer conntrack->tuplehash[...].list is
stored. This cannot be aliased via container_of because
tuplehash_to_ctrack doesn't pass a constant argument to it and cannot
be determined at compile time. Try the attached patch.
Note that you can get some false positives that might disappear after
a while. This is because of the stacks scanning and also pointers
stored in CPU registers, especially on SMP systems.
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]
