Home » Mailing list archives » linux-kernel » 2007 » September » 18

Re: 2.6.23-rc6-mm1 panic (memory controller issue ?)

Previous thread: [patch 06/11] Text Edit Lock - Alternative code for i386 and x86_64 by Mathieu Desnoyers on Tuesday, September 18, 2007 - 5:06 pm. (1 message)

Next thread: BUG? Suspend during active sound playback kills sound by Shentino on Tuesday, September 18, 2007 - 7:06 pm. (2 messages)
[view original message]
From: Badari Pulavarty <pbadari@...>
To: Andrew Morton <akpm@...>, <balbir@...>, <clameter@...>
Cc: lkml <linux-kernel@...>
Subject: 2.6.23-rc6-mm1 panic (memory controller issue ?)
Date: Tuesday, September 18, 2007 - 6:21 pm

Hi Balbir,


I get following panic from SLUB, while doing simple fsx tests.

I haven't used any container/memory controller stuff except

that I configured them in :(


Looks like slub doesn't like one of the flags passed in ?


Known issue ? Ideas ?


Thanks,

Badari


CONFIG_CONTAINERS=y

CONFIG_CONTAINER_DEBUG=y

CONFIG_CONTAINER_NS=y

CONFIG_CONTAINER_CPUACCT=y

CONFIG_CONTAINER_MEM_CONT=y

CONFIG_ACPI_CONTAINER=m


elm3b29 login: ------------[ cut here ]------------

kernel BUG at mm/slub.c:1093!

invalid opcode: 0000 [1] SMP

last sysfs file: /power/state

CPU 3

Modules linked in:

Pid: 3885, comm: fsx-linux Not tainted 2.6.23-rc6-mm1 #2

RIP: 0010:[<ffffffff8029a458>]  [<ffffffff8029a458>] new_slab

+0x238/0x260

RSP: 0018:ffff81010140faf8  EFLAGS: 00010202

RAX: 0000000000000305 RBX: 0000000000000000 RCX: 00000000ffffffff

RDX: 00000000ffffffff RSI: 00000000001280d2 RDI: ffffffff806f3240

RBP: ffff81010140fb28 R08: 0000000000000040 R09: 0000000000000000

R10: 00000000000160c9 R11: 0000000000000002 R12: ffff8101c00146c0

R13: ffffffff806f3240 R14: ffffffff806f3240 R15: 00000000ffffffff

FS:  00007f7668f546d0(0000) GS:ffff8101c0729400(0000)

knlGS:0000000055749930

CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b

CR2: 00007f7668f6c000 CR3: 00000001821c1000 CR4: 00000000000006e0

DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

Process fsx-linux (pid: 3885, threadinfo ffff81010140e000, task

ffff81010158aca0)

last branch before last exception/interrupt

 from  [<ffffffff8029a23c>] new_slab+0x1c/0x260

 to  [<ffffffff8029a458>] new_slab+0x238/0x260

Stack:  ffff8101c0729290 0000000000000000 ffff8101c00146c0

ffff8101df8618c0

 ffffffff806f3240 00000000ffffffff ffff81010140fb78 ffffffff8029a620

 001200d200000000 ffffffff8029eb10 001280d200000002 0000000000000000

Call Trace:

 [<ffffffff8029a620>] __slab_alloc+0x1a0/0x450

 [<ffffffff8029eb10>] mem_container_charge+0x90/0x2a0

...
[ message continues ]
[view original message]
From: Badari Pulavarty <pbadari@...>
To: Andrew Morton <akpm@...>
Cc: <balbir@...>, <clameter@...>, lkml <linux-kernel@...>
Subject: Re: 2.6.23-rc6-mm1 panic (memory controller issue ?)
Date: Tuesday, September 18, 2007 - 8:31 pm

I think, I found the issue. I am still running tests to

verify. Does this sound correct ?


Thanks,

Badari


Need to strip __GFP_HIGHMEM flag while passing to mem_container_cache_charge().


Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>

 mm/filemap.c |    3 ++-

 1 file changed, 2 insertions(+), 1 deletion(-)


Index: linux-2.6.23-rc6/mm/filemap.c

===================================================================

--- linux-2.6.23-rc6.orig/mm/filemap.c	2007-09-18 12:43:54.000000000 -0700

+++ linux-2.6.23-rc6/mm/filemap.c	2007-09-18 19:14:44.000000000 -0700

@@ -441,7 +441,8 @@ int filemap_write_and_wait_range(struct

 int add_to_page_cache(struct page *page, struct address_space *mapping,

 		pgoff_t offset, gfp_t gfp_mask)

 {

-	int error = mem_container_cache_charge(page, current->mm, gfp_mask);

+	int error = mem_container_cache_charge(page, current->mm,

+			gfp_mask & ~__GFP_HIGHMEM);

 	if (error)

 		goto out;


-
[view original message]
From: Christoph Lameter <clameter@...>
To: Badari Pulavarty <pbadari@...>
Cc: Andrew Morton <akpm@...>, <balbir@...>, lkml <linux-kernel@...>
Subject: Re: 2.6.23-rc6-mm1 panic (memory controller issue ?)
Date: Wednesday, September 19, 2007 - 1:24 pm

Use GFP_LEVEL_MASK (or the equivalent in mm) to mask out the not allowed

bits. The patch below only addresses issues with the __GFP_HIGHMEM bit.

There may be others set. See mm/vmalloc.c for examples.


-
[view original message]
From: Balbir Singh <balbir@...>
To: Badari Pulavarty <pbadari@...>
Cc: Andrew Morton <akpm@...>, <balbir@...>, <clameter@...>, lkml <linux-kernel@...>
Subject: Re: 2.6.23-rc6-mm1 panic (memory controller issue ?)
Date: Tuesday, September 18, 2007 - 9:53 pm

Hi, Badari,


The fix looks correct, radix_tree_preload() does the same thing in

add_to_page_cache(). Thanks for identifying the fix


--

	Warm Regards,

	Balbir Singh

	Linux Technology Center

	IBM, ISTL

-
[view original message]
From: Christoph Lameter <clameter@...>
To: Balbir Singh <balbir@...>
Cc: Badari Pulavarty <pbadari@...>, Andrew Morton <akpm@...>, <balbir@...>, lkml <linux-kernel@...>
Subject: Re: 2.6.23-rc6-mm1 panic (memory controller issue ?)
Date: Wednesday, September 19, 2007 - 1:25 pm

Hmmm.... Radix tree preload can only take a limited set of flags?


-
[view original message]
From: Balbir Singh <balbir@...>
To: Christoph Lameter <clameter@...>
Cc: Badari Pulavarty <pbadari@...>, Andrew Morton <akpm@...>, <balbir@...>, lkml <linux-kernel@...>
Subject: Re: 2.6.23-rc6-mm1 panic (memory controller issue ?)
Date: Wednesday, September 19, 2007 - 2:18 pm

Yes, the whole code is very interesting. From add_to_page_cache()

we call radix_tree_preload with __GFP_HIGHMEM cleared, but

from __add_to_swap_cache(), we don't make any changes to the

gfp_mask. radix_tree_preload() calls kmem_cache_alloc() and in slub

there is a check


        BUG_ON(flags & GFP_SLAB_BUG_MASK);


So, I guess all our allocations should check against __GFP_DMA and

__GFP_HIGHMEM. I'll review the code, test it and send a fix.


--

	Warm Regards,

	Balbir Singh

	Linux Technology Center

	IBM, ISTL

-
[view original message]
From: Christoph Lameter <clameter@...>
To: Balbir Singh <balbir@...>
Cc: Badari Pulavarty <pbadari@...>, Andrew Morton <akpm@...>, <balbir@...>, lkml <linux-kernel@...>
Subject: Re: 2.6.23-rc6-mm1 panic (memory controller issue ?)
Date: Wednesday, September 19, 2007 - 2:54 pm

You need to use the proper mask from include/linux/gfp.h. Masking

individual bits will create problems when we create new bits.


-
[view original message]
From: Balbir Singh <balbir@...>
To: Christoph Lameter <clameter@...>
Cc: Badari Pulavarty <pbadari@...>, Andrew Morton <akpm@...>, <balbir@...>, lkml <linux-kernel@...>
Subject: Re: 2.6.23-rc6-mm1 panic (memory controller issue ?)
Date: Wednesday, September 19, 2007 - 3:04 pm

I agree 100%, that's why I want to review the code. I want to use

a mask that clears the GFP_SLAB_BUG_MASK bits and review it. I want

to check against other call sites that use gfp_mask as well.


--

	Warm Regards,

	Balbir Singh

	Linux Technology Center

	IBM, ISTL

-
Previous thread: [patch 06/11] Text Edit Lock - Alternative code for i386 and x86_64 by Mathieu Desnoyers on Tuesday, September 18, 2007 - 5:06 pm. (1 message)

Next thread: BUG? Suspend during active sound playback kills sound by Shentino on Tuesday, September 18, 2007 - 7:06 pm. (2 messages)