From: Mike Kazantsev <mk.fraggod@gmail.com>
To: Paul Moore <paul@paul-moore.com>
Cc: netdev@vger.kernel.org, linux-mm@kvack.org
Subject: Re: PROBLEM: Memory leak (at least with SLUB) from "secpath_dup" (xfrm) in 3.5+ kernels
Date: Sat, 20 Oct 2012 20:49:58 +0600 [thread overview]
Message-ID: <20121020204958.4bc8e293@sacrilege> (raw)
In-Reply-To: <CAHC9VhQ+gkAaRmwDWqzQd1U-hwH__5yxrxWa5_=koz_XTSXpjQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1911 bytes --]
On Sat, 20 Oct 2012 08:42:33 -0400
Paul Moore <paul@paul-moore.com> wrote:
> Thanks for the problem report. I'm not going to be in a position to start
> looking into this until late Sunday, but hopefully it will be a quick fix.
>
> Two quick questions (my apologies, I'm not able to dig through your logs
> right now): do you see this leak on kernels < 3.5.0, and are you using any
> labeled IPsec connections?
>
As I understand, labelled connections are only used in SELinux
and SMACK LSM, which are not enabled (in Kconfig, i.e. not built) in any
of the kernels I use.
The only LSM I have enabled (and actually use on 2/4 of these machines)
is AppArmor, and though I think it doesn't attach any labels to network
connections yet (there's a "Wishlist" bug at
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/796588, but I
can't seem to find an existing implementation).
I believe it has started with 3.5.0, according to all available logs I
have. I'm afraid laziness and other tasks have prevented me from
looking into and reporting the issue back then, but memory graph trends
start at the exact time of reboot into 3.5.0 kernels, and before that,
there're no such trends for slab memory usage.
I've been able to ignore and work around the problem for months now, so
I don't think there's any rush at all ;)
But that said, currently I've started git bisect process between v3.5
and v3.4 tags, so hopefully I'll get good-enough results of it before
you'll get to it (probably in a few hours to a few days).
Also, I've found that switching to "slab" allocator from "slub" doesn't
help the problem at all, so I guess something doesn't get freed in the
code indeed, though I hasn't been able to find anything relevant in the
logs for the sources where secpath_put and secpath_dup are used, and
decided to try bisect.
--
Mike Kazantsev // fraggod.net
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2012-10-20 14:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-19 14:50 PROBLEM: Memory leak (at least with SLUB) from "secpath_dup" (xfrm) in 3.5+ kernels Mike Kazantsev
2012-10-19 17:36 ` Mike Kazantsev
2012-10-20 12:42 ` Paul Moore
2012-10-20 14:49 ` Mike Kazantsev [this message]
2012-10-20 22:45 ` Mike Kazantsev
2012-10-21 0:24 ` Mike Kazantsev
2012-10-21 13:29 ` Eric Dumazet
2012-10-21 13:57 ` Mike Kazantsev
2012-10-21 18:43 ` Mike Kazantsev
2012-10-21 19:51 ` Mike Kazantsev
2012-10-21 21:47 ` Eric Dumazet
2012-10-21 22:58 ` Mike Kazantsev
2012-10-22 8:15 ` Eric Dumazet
2012-10-22 12:06 ` Mike Kazantsev
2012-10-22 15:16 ` Eric Dumazet
2012-10-22 15:22 ` Eric Dumazet
2012-10-22 15:28 ` Eric Dumazet
2012-10-22 16:59 ` Mike Kazantsev
2012-10-22 17:24 ` Eric Dumazet
2012-10-22 19:03 ` [PATCH] net: fix secpath kmemleak Eric Dumazet
2012-10-22 19:17 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121020204958.4bc8e293@sacrilege \
--to=mk.fraggod@gmail.com \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=paul@paul-moore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).