From: Glauber Costa <glommer@parallels.com>
To: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>,
linux-mm@kvack.org, David Rientjes <rientjes@google.com>,
Joonsoo Kim <js1304@gmail.com>
Subject: Re: Common [00/16] Sl[auo]b: Common code rework V8
Date: Thu, 2 Aug 2012 12:49:34 +0400 [thread overview]
Message-ID: <501A3F1E.4060307@parallels.com> (raw)
In-Reply-To: <20120801211130.025389154@linux.com>
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
On 08/02/2012 01:11 AM, Christoph Lameter wrote:
>
> V7->V8:
> - Do not use kfree for kmem_cache in slub.
> - Add more patches up to a common
> scheme for object alignment.
>
> V6->V7:
> - Omit pieces that were merged for 3.6
> - Fix issues pointed out by Glauber.
> - Include the patches up to the point at which
> the slab name handling is unified
>
After applying v8, and proceeding with cache deletion + later insertion
as I've previously laid down, I can still see the bug I mentioned here.
Again, I am doing nothing more than:
1) Creating a cache
2) Deleting that cache
3) Creating that cache again.
I am doing this in a synthetic function "mybug" called from memcg
creation for convenience only (so don't get distracted by this in the
backtrack). The machine boots okay, and seems to work for everything
other than those late destructions. So maybe this is a problem that
happens only after SLAB_FULL?
I am attaching the backtrace I've got with SLUB_DEBUG_ON. My first guess
based on it would be a double free somewhere.
[-- Attachment #2: serial --]
[-- Type: text/plain, Size: 2497 bytes --]
containers2 login: [ 28.399559] general protection fault: 0000 [#1] SMP
[ 28.400532] CPU 0
[ 28.400532] Modules linked in:
[ 28.400532]
[ 28.400532] Pid: 1143, comm: mkdir Not tainted 3.5.0-rc1+ #387 Bochs Bochs
[ 28.400532] RIP: 0010:[<ffffffff8112fed3>] [<ffffffff8112fed3>] virt_to_head_page+0x1e/0x2c
[ 28.400532] RSP: 0018:ffff8800378a1db8 EFLAGS: 00010203
[ 28.400532] RAX: 01ad998dadadad80 RBX: 6b6b6b6b6b6b6b6b RCX: ffff88003f388730
[ 28.400532] RDX: ffffea0000000000 RSI: ffff88003f388708 RDI: 6b6b6b6b6b6b6b6b
[ 28.400532] RBP: ffff8800378a1db8 R08: dead000000200200 R09: 2b508c806051e290
[ 28.400532] R10: 0000000000000020 R11: ffff88003ea13b68 R12: ffff880037a8db38
[ 28.400532] R13: ffffffff81110fef R14: ffff880037a50fd8 R15: 0000000000000000
[ 28.400532] FS: 00007fe7352057c0(0000) GS:ffff88003ea00000(0000) knlGS:0000000000000000
[ 28.400532] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 28.400532] CR2: 00007f5004de9000 CR3: 000000003b6db000 CR4: 00000000000006f0
[ 28.400532] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 28.400532] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 28.400532] Process mkdir (pid: 1143, threadinfo ffff8800378a0000, task ffff88003f388000)
[ 28.400532] Stack:
[ 28.400532] ffff8800378a1de8 ffffffff81132b59 ffff880037a8dad0 ffff880037a8db38
[ 28.400532] 0000000000000004 ffff880037a50fd8 ffff8800378a1e08 ffffffff81110fef
[ 28.400532] ffffc90000861000 ffffc90000184000 ffff8800378a1e28 ffffffff8113ee33
[ 28.400532] Call Trace:
[ 28.400532] [<ffffffff81132b59>] kfree+0x4c/0xfb
[ 28.400532] [<ffffffff81110fef>] kmem_cache_destroy+0x53/0xa7
[ 28.400532] [<ffffffff8113ee33>] mybug+0x4a/0xa3
[ 28.400532] [<ffffffff814fa71c>] mem_cgroup_create+0x2db/0x423
[ 28.400532] [<ffffffff810a6f8e>] cgroup_mkdir+0xd1/0x37c
[ 28.400532] [<ffffffff8114df09>] vfs_mkdir+0x7e/0xcd
[ 28.400532] [<ffffffff8114f848>] sys_mkdirat+0x6f/0xae
[ 28.400532] [<ffffffff8114f8a0>] sys_mkdir+0x19/0x1b
[ 28.400532] [<ffffffff81523369>] system_call_fastpath+0x16/0x1b
[ 28.400532] Code: f9 03 48 89 e5 48 83 e1 f8 f3 aa 5d c3 55 48 89 e5 e8 1e 78 f0 ff 48 c1 e8 0c 48 ba 00 00 00 00 00 ea ff ff 48 c1 e0 06 48 01 d0 <48> 8b 10 80 e6 80 74 04 48 8b 40 30 5d c3 55 48 89 e5 53 50 66
[ 28.400532] RIP [<ffffffff8112fed3>] virt_to_head_page+0x1e/0x2c
[ 28.400532] RSP <ffff8800378a1db8>
[ 28.440928] ---[ end trace 75e62f10600e2a23 ]---
next prev parent reply other threads:[~2012-08-02 8:52 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-01 21:11 Christoph Lameter
2012-08-01 21:11 ` Common [01/16] slub: Add debugging to verify correct cache use on kmem_cache_free() Christoph Lameter
2012-08-01 21:11 ` Common [02/16] slub: Use kmem_cache for the kmem_cache structure Christoph Lameter
2012-08-01 21:11 ` Common [03/16] Move list_add() to slab_common.c Christoph Lameter
2012-08-01 21:11 ` Common [04/16] Extract a common function for kmem_cache_destroy Christoph Lameter
2012-08-01 21:11 ` Common [05/16] Always use the name "kmem_cache" for the slab cache with the kmem_cache structure Christoph Lameter
2012-08-01 21:11 ` Common [06/16] Move freeing of kmem_cache structure to common code Christoph Lameter
2012-08-01 21:11 ` Common [07/16] Get rid of __kmem_cache_destroy Christoph Lameter
2012-08-01 21:11 ` Common [08/16] Move duping of slab name to slab_common.c Christoph Lameter
2012-08-02 15:41 ` Christoph Lameter
2012-08-01 21:11 ` Common [09/16] Do slab aliasing call from common code Christoph Lameter
2012-08-02 9:29 ` Glauber Costa
2012-08-02 14:13 ` Christoph Lameter
2012-08-01 21:11 ` Common [10/16] Move sysfs_slab_add to common Christoph Lameter
2012-08-01 21:11 ` Common [11/16] slub: Use a statically allocated kmem_cache boot structure for bootstrap Christoph Lameter
2012-08-02 10:11 ` Glauber Costa
2012-08-01 21:11 ` Common [12/16] create common create_kmalloc_cache() Christoph Lameter
2012-08-02 10:22 ` Glauber Costa
2012-08-01 21:11 ` Common [13/16] slub: Introduce function for opening boot caches Christoph Lameter
2012-08-02 10:25 ` Glauber Costa
2012-08-02 14:14 ` Christoph Lameter
2012-08-01 21:11 ` Common [14/16] Move kmem_cache allocations into common code Christoph Lameter
2012-08-02 10:32 ` Glauber Costa
2012-08-02 14:15 ` Christoph Lameter
2012-08-01 21:11 ` Common [15/16] Shrink __kmem_cache_create() parameter lists Christoph Lameter
2012-08-02 8:19 ` Glauber Costa
2012-08-02 14:11 ` Christoph Lameter
2012-08-02 14:14 ` Glauber Costa
2012-08-02 10:34 ` Glauber Costa
2012-08-02 14:31 ` Christoph Lameter
2012-08-02 14:34 ` Christoph Lameter
2012-08-01 21:11 ` Common [16/16] Common alignment code Christoph Lameter
2012-08-02 7:59 ` Common [00/16] Sl[auo]b: Common code rework V8 Glauber Costa
2012-08-02 14:10 ` Christoph Lameter
2012-08-02 8:49 ` Glauber Costa [this message]
2012-08-02 9:18 ` Glauber Costa
2012-08-02 14:13 ` Christoph Lameter
2012-08-02 14:17 ` Glauber Costa
2012-08-02 14:28 ` Christoph Lameter
2012-08-02 14:46 ` Glauber Costa
2012-08-02 14:45 ` Christoph Lameter
2012-08-02 14:47 ` Glauber Costa
2012-08-02 15:13 ` Christoph Lameter
2012-08-02 15:19 ` Christoph Lameter
2012-08-02 18:07 ` Christoph Lameter
2012-08-02 18:09 ` Glauber Costa
2012-08-02 18:13 ` Christoph Lameter
2012-08-02 18:27 ` Christoph Lameter
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=501A3F1E.4060307@parallels.com \
--to=glommer@parallels.com \
--cc=cl@linux.com \
--cc=js1304@gmail.com \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.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