linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mike Kazantsev <mk.fraggod@gmail.com>
To: linux-mm@kvack.org
Cc: paul@paul-moore.com, netdev@vger.kernel.org
Subject: Re: PROBLEM: Memory leak (at least with SLUB) from "secpath_dup" (xfrm) in 3.5+ kernels
Date: Fri, 19 Oct 2012 23:36:32 +0600	[thread overview]
Message-ID: <20121019233632.26cf96d8@sacrilege> (raw)
In-Reply-To: <20121019205055.2b258d09@sacrilege>

[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]

On Fri, 19 Oct 2012 20:50:55 +0600
Mike Kazantsev <mk.fraggod@gmail.com> wrote:

> slabtop showed "kmalloc-64" being the 99% offender in the past, but
> with recent kernels (3.6.1), it has changed to "secpath_cache"

To be more specific, on 3.5.4 kernel leak looks like this:

 Active / Total Objects (% used)    : 19971419 / 20084060 (99.4%)
 Active / Total Slabs (% used)      : 318645 / 318645 (100.0%)
 Active / Total Caches (% used)     : 79 / 121 (65.3%)
 Active / Total Size (% used)       : 1285299.85K / 1307992.83K (98.3%)
 Minimum / Average / Maximum Object : 0.01K / 0.06K / 8.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
19678272 19678272 100%    0.06K 307473       64   1229892K kmalloc-64             
159198  95262  59%    0.10K   4082       39     16328K buffer_head            
 32865  17515  53%    0.19K   1565       21      6260K dentry                 
 20480  19456  95%    0.02K     80      256       320K ext4_io_page           
 16896  10380  61%    0.03K    132      128       528K kmalloc-32             
 16164  16164 100%    0.11K    449       36      1796K sysfs_dir_cache        
 15980  15980 100%    0.02K     94      170       376K fsnotify_event_holder  
 14742   9205  62%    0.87K    819       18     13104K ext4_inode_cache       
 13916   5494  39%    0.55K    497       28      7952K radix_tree_node        
 10030   5172  51%    0.05K    118       85       472K anon_vma_chain         
 10020  10020 100%    0.13K    334       30      1336K ext4_allocation_context
  9486   9398  99%    0.04K     93      102       372K Acpi-Namespace         
  8192   8192 100%    0.01K     16      512        64K kmalloc-8              
  6960   6016  86%    0.25K    435       16      1740K kmalloc-256            
  6641   5412  81%    0.55K    229       29      3664K inode_cache            
  5124   4333  84%    0.19K    244       21       976K kmalloc-192

Unfortunately, kernel on this machine isn't booted with slub_debug
options (yet), so there're no specific on whether it's allocated (as I
understand it) in the same call or a different one.

Not sure if it's even possible that it might be the same call.


-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2012-10-19 17:36 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 [this message]
2012-10-20 12:42   ` Paul Moore
2012-10-20 14:49     ` Mike Kazantsev
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=20121019233632.26cf96d8@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).