[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121022180655.50a50401@sacrilege>
Date: Mon, 22 Oct 2012 18:06:55 +0600
From: Mike Kazantsev <mk.fraggod@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Paul Moore <paul@...l-moore.com>, netdev@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: PROBLEM: Memory leak (at least with SLUB) from "secpath_dup"
(xfrm) in 3.5+ kernels
On Mon, 22 Oct 2012 10:15:43 +0200
Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Mon, 2012-10-22 at 04:58 +0600, Mike Kazantsev wrote:
>
> > I've grepped for "/org/free" specifically and sure enough, same scraps
> > of data seem to be in some of the (varied) dumps there.
>
> Content is not meaningful, as we dont initialize it.
> So you see previous content.
>
> Could you try the following :
>
...
With this patch on top of v3.7-rc2 (w/o patches from your previous
mail), leak seem to be still present.
If I understand correctly, WARN_ON_ONCE should've produced some output
in dmesg when the conditions passed to it were met.
They don't appear to be, as the only output in dmesg during
ipsec-related modules loading (I think openswan probes them manually)
is still "AVX instructions are not detected" (can be seen in tty on
boot) and the only post-boot dmesg output (incl. during leaks
happening) is from kmemleak ("kmemleak: ... new suspected memory
leaks").
Looks like kmem_cache_zalloc got rid of the content, though traces
still report it as "kmem_cache_alloc", but I guess it's because of its
"inline" nature.
--
Mike Kazantsev // fraggod.net
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists