Re: 2.6.23-rc6-mm1 panic (memory controller issue ?)
Christoph Lameter wrote: > On Wed, 19 Sep 2007, Balbir Singh wrote: > >> 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. > > You need to use the proper mask from include/linux/gfp.h. Masking > individual bits will create problems when we create new bits. > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc6-mm1 panic (memory controller issue ?)
On Wed, 19 Sep 2007, Balbir Singh wrote: > 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. You need to use the proper mask from include/linux/gfp.h. Masking individual bits will create problems when we create new bits. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc6-mm1 panic (memory controller issue ?)
Christoph Lameter wrote: > On Wed, 19 Sep 2007, Balbir Singh wrote: > >> The fix looks correct, radix_tree_preload() does the same thing in >> add_to_page_cache(). Thanks for identifying the fix > > Hmmm Radix tree preload can only take a limited set of flags? > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc6-mm1 panic (memory controller issue ?)
On Wed, 19 Sep 2007, Balbir Singh wrote: > The fix looks correct, radix_tree_preload() does the same thing in > add_to_page_cache(). Thanks for identifying the fix Hmmm Radix tree preload can only take a limited set of flags? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc6-mm1 panic (memory controller issue ?)
On Tue, 18 Sep 2007, Badari Pulavarty wrote: > I think, I found the issue. I am still running tests to > verify. Does this sound correct ? 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc6-mm1 panic (memory controller issue ?)
Badari Pulavarty wrote:
> On Tue, 2007-09-18 at 15:21 -0700, Badari Pulavarty wrote:
>> 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 ?
>>
>
> 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 <[EMAIL PROTECTED]>
> 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.c2007-09-18 12:43:54.0
> -0700
> +++ linux-2.6.23-rc6/mm/filemap.c 2007-09-18 19:14:44.0 -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;
>
>
>
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc6-mm1 panic (memory controller issue ?)
On Tue, 2007-09-18 at 15:21 -0700, Badari Pulavarty wrote:
> 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 ?
>
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 <[EMAIL PROTECTED]>
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.0 -0700
+++ linux-2.6.23-rc6/mm/filemap.c 2007-09-18 19:14:44.0 -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;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc6-mm1 panic (memory controller issue ?)
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: [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:[] [] new_slab +0x238/0x260 RSP: 0018:81010140faf8 EFLAGS: 00010202 RAX: 0305 RBX: RCX: RDX: RSI: 001280d2 RDI: 806f3240 RBP: 81010140fb28 R08: 0040 R09: R10: 000160c9 R11: 0002 R12: 8101c00146c0 R13: 806f3240 R14: 806f3240 R15: FS: 7f7668f546d0() GS:8101c0729400() knlGS:55749930 CS: 0010 DS: ES: CR0: 8005003b CR2: 7f7668f6c000 CR3: 0001821c1000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process fsx-linux (pid: 3885, threadinfo 81010140e000, task 81010158aca0) last branch before last exception/interrupt from [] new_slab+0x1c/0x260 to [] new_slab+0x238/0x260 Stack: 8101c0729290 8101c00146c0 8101df8618c0 806f3240 81010140fb78 8029a620 001200d2 8029eb10 001280d20002 Call Trace: [] __slab_alloc+0x1a0/0x450 [] mem_container_charge+0x90/0x2a0 [] kmem_cache_alloc+0x7b/0xa0 [] mem_container_charge+0x90/0x2a0 [] __alloc_pages+0x6e/0x360 [] mem_container_cache_charge+0x2b/0x40 [] add_to_page_cache+0x3e/0x120 [] add_to_page_cache_lru+0x19/0x40 [] find_or_create_page+0x5c/0xa0 [] ext3_truncate+0x342/0x990 [] mem_container_charge+0x42/0x2a0 [] unlock_page+0x2d/0x40 [] __do_fault+0x10f/0x3f0 [] __dec_zone_page_state+0x25/0x30 [] page_remove_rmap+0x46/0x140 [] vmtruncate+0xb0/0x110 [] inode_setattr+0x30/0x180 [] ext3_setattr+0x12c/0x240 [] notify_change+0x380/0x3e0 [] do_truncate+0x63/0x90 [] generic_file_llseek+0x61/0xc0 [] sys_ftruncate+0xd6/0x120 [] system_call+0x7e/0x83 Code: 0f 0b eb fe 66 66 66 90 41 8b 4d 14 ba 00 10 00 00 be 5a 00 RIP [] new_slab+0x238/0x260 RSP - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
