[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121022004332.7e3f3f29@sacrilege>
Date: Mon, 22 Oct 2012 00:43:32 +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 Sun, 21 Oct 2012 19:57:01 +0600
Mike Kazantsev <mk.fraggod@...il.com> wrote:
> On Sun, 21 Oct 2012 15:29:43 +0200
> Eric Dumazet <eric.dumazet@...il.com> wrote:
>
> >
> > Did you try linux-3.7-rc2 (or linux-3.7-rc1) ?
> >
>
> I did not, will do in a few hours, thanks for the pointer.
>
I just built "torvalds/linux-2.6" (v3.7-rc2) and rebooted into it,
started same rsync-over-net test and got kmalloc-64 leaking (it went up
to tens of MiB until I stopped rsync, normally these are fixed at ~500
KiB).
Unfortunately, I forgot to add slub_debug option and build kmemleak so
wasn't able to look at this case further, and when I rebooted with
these enabled/built, it was secpath_cache again.
So previously noted "slabtop showed 'kmalloc-64' being the 99% offender
in the past, but with recent kernels (3.6.1), it has changed to
'secpath_cache'" seem to be incorrect, as it seem to depend not on
kernel version, but some other factor.
Guess I'll try to reboot a few more times to see if I can catch
kmalloc-64 leaking (instead of secpath_cache) again.
--
Mike Kazantsev // fraggod.net
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists