lkml.org 
[lkml]   [2006]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2.6.18-rc4 00/10] Kernel memory leak detector 0.9
On 18/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> On 18/08/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> > On 18/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > > Lockdep still detects this bug
> >
> > Do you have the complete dmesg output? There should be a different
> > path which I missed (I didn't get this yestarday but I haven't tried
> > with the latest patch I sent to you today).
>
> Here is dmesg output
> http://www.stardust.webpages.pl/files/o_bugs/kmemleak-0.9/kml-dmesg2

Thanks. It is strange - I was under the impression that calling
radix_tree_preload() outside the memleak_lock holding would actually
prevent radix_tree_insert() from allocating a node (and therefore call
kmem_cache_alloc and acquire the list_lock). I'll look at the
radix_tree code this weekend. I'm looking at implementing some kind of
RCU mechanism in kmemleak to avoid future problems (might need changed
to radix_tree as well).

--
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/

\
 
 \ /
  Last update: 2006-08-18 19:01    [W:4.994 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site