Re: [PATCH 00/10] Kernel memory leak detector 0.8

["Catalin Marinas" <catalin.marinas@gmail.com>]

On 12/07/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/