Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Andrew Morton]

On Tue, 04 Mar 2008 18:42:19 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:

> 3) Third attempt kernel booted up but had the following call trace 264 times while running
> test
> 
> Badness at include/linux/gfp.h:110
> NIP: c0000000000b4ff0 LR: c0000000000b4fa0 CTR: c00000000019cdb4
> REGS: c000000009edf250 TRAP: 0700   Not tainted  (2.6.25-rc3-mm1-autotest)
> MSR: 8000000000029032 <EE,ME,IR,DR>  CR: 22024042  XER: 20000003
> TASK = c000000009062140[548] 'kjournald' THREAD: c000000009edc000 CPU: 0
> NIP [c0000000000b4ff0] .get_page_from_freelist+0x29c/0x898
> LR [c0000000000b4fa0] .get_page_from_freelist+0x24c/0x898
> Call Trace:
> [c000000009edf5f0] [c0000000000b56e4] .__alloc_pages_internal+0xf8/0x470
> [c000000009edf6e0] [c0000000000e0458] .kmem_getpages+0x8c/0x194
> [c000000009edf770] [c0000000000e1050] .fallback_alloc+0x194/0x254
> [c000000009edf820] [c0000000000e14b0] .kmem_cache_alloc+0xd8/0x144
> [c000000009edf8c0] [c0000000001fe0f8] .radix_tree_preload+0x50/0xd4
> [c000000009edf960] [c0000000000ad048] .add_to_page_cache+0x38/0x12c
> [c000000009edfa00] [c0000000000ad158] .add_to_page_cache_lru+0x1c/0x4c
> [c000000009edfa90] [c0000000000add58] .find_or_create_page+0x60/0xa8
> [c000000009edfb30] [c00000000011e478] .__getblk+0x140/0x310
> [c000000009edfc00] [c0000000001b78c4] .journal_get_descriptor_buffer+0x44/0xd8
> [c000000009edfca0] [c0000000001b236c] .journal_commit_transaction+0x948/0x1590
> [c000000009edfe00] [c0000000001b585c] .kjournald+0xf4/0x2ac
> [c000000009edff00] [c00000000007ff4c] .kthread+0x84/0xd0
> [c000000009edff90] [c000000000028900] .kernel_thread+0x4c/0x68
> Instruction dump:
> 7dc57378 48009575 60000000 2fa30000 419e0490 56c902d8 3c000018 7dd907b4 
> 7ad2c7e2 7f890000 7c000026 5400fffe <0b000000> e93e8128 3b000000 80090000 

/* Convert GFP flags to their corresponding migrate type */
static inline int allocflags_to_migratetype(gfp_t gfp_flags)
{
        WARN_ON((gfp_flags & GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);

Mel, Pekka: would you have some head-scratching time for this one please?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Pekka Enberg]

On Tue, 04 Mar 2008 18:42:19 +0530 Kamalesh Babulal
<kamalesh@linux.vnet.ibm.com> wrote:
>  > 3) Third attempt kernel booted up but had the following call trace 264 times while running
>  > test
>  >
>  > Badness at include/linux/gfp.h:110
>  > NIP: c0000000000b4ff0 LR: c0000000000b4fa0 CTR: c00000000019cdb4
>  > REGS: c000000009edf250 TRAP: 0700   Not tainted  (2.6.25-rc3-mm1-autotest)
>  > MSR: 8000000000029032 <EE,ME,IR,DR>  CR: 22024042  XER: 20000003
>  > TASK = c000000009062140[548] 'kjournald' THREAD: c000000009edc000 CPU: 0
>  > NIP [c0000000000b4ff0] .get_page_from_freelist+0x29c/0x898
>  > LR [c0000000000b4fa0] .get_page_from_freelist+0x24c/0x898
>  > Call Trace:
>  > [c000000009edf5f0] [c0000000000b56e4] .__alloc_pages_internal+0xf8/0x470
>  > [c000000009edf6e0] [c0000000000e0458] .kmem_getpages+0x8c/0x194
>  > [c000000009edf770] [c0000000000e1050] .fallback_alloc+0x194/0x254
>  > [c000000009edf820] [c0000000000e14b0] .kmem_cache_alloc+0xd8/0x144
>  > [c000000009edf8c0] [c0000000001fe0f8] .radix_tree_preload+0x50/0xd4
>  > [c000000009edf960] [c0000000000ad048] .add_to_page_cache+0x38/0x12c
>  > [c000000009edfa00] [c0000000000ad158] .add_to_page_cache_lru+0x1c/0x4c
>  > [c000000009edfa90] [c0000000000add58] .find_or_create_page+0x60/0xa8
>  > [c000000009edfb30] [c00000000011e478] .__getblk+0x140/0x310
>  > [c000000009edfc00] [c0000000001b78c4] .journal_get_descriptor_buffer+0x44/0xd8
>  > [c000000009edfca0] [c0000000001b236c] .journal_commit_transaction+0x948/0x1590
>  > [c000000009edfe00] [c0000000001b585c] .kjournald+0xf4/0x2ac
>  > [c000000009edff00] [c00000000007ff4c] .kthread+0x84/0xd0
>  > [c000000009edff90] [c000000000028900] .kernel_thread+0x4c/0x68
>  > Instruction dump:
>  > 7dc57378 48009575 60000000 2fa30000 419e0490 56c902d8 3c000018 7dd907b4
>  > 7ad2c7e2 7f890000 7c000026 5400fffe <0b000000> e93e8128 3b000000 80090000

On Tue, Mar 4, 2008 at 8:36 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>  /* Convert GFP flags to their corresponding migrate type */
>  static inline int allocflags_to_migratetype(gfp_t gfp_flags)
>  {
>         WARN_ON((gfp_flags & GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
>
>  Mel, Pekka: would you have some head-scratching time for this one please?

Sure. Just to double-check, this is with SLAB, right? Do you see this with SLUB?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Pekka Enberg]

Andrew Morton wrote:
> > [c000000009edf5f0] [c0000000000b56e4] .__alloc_pages_internal+0xf8/0x470
> > [c000000009edf6e0] [c0000000000e0458] .kmem_getpages+0x8c/0x194
> > [c000000009edf770] [c0000000000e1050] .fallback_alloc+0x194/0x254
> > [c000000009edf820] [c0000000000e14b0] .kmem_cache_alloc+0xd8/0x144
> > [c000000009edf8c0] [c0000000001fe0f8] .radix_tree_preload+0x50/0xd4
> > [c000000009edf960] [c0000000000ad048] .add_to_page_cache+0x38/0x12c
> > [c000000009edfa00] [c0000000000ad158] .add_to_page_cache_lru+0x1c/0x4c
> > [c000000009edfa90] [c0000000000add58] .find_or_create_page+0x60/0xa8
> > [c000000009edfb30] [c00000000011e478] .__getblk+0x140/0x310
> > [c000000009edfc00] [c0000000001b78c4] .journal_get_descriptor_buffer+0x44/0xd8
> > [c000000009edfca0] [c0000000001b236c] .journal_commit_transaction+0x948/0x1590
> > [c000000009edfe00] [c0000000001b585c] .kjournald+0xf4/0x2ac
> > [c000000009edff00] [c00000000007ff4c] .kthread+0x84/0xd0
> > [c000000009edff90] [c000000000028900] .kernel_thread+0x4c/0x68
> > Instruction dump:
> > 7dc57378 48009575 60000000 2fa30000 419e0490 56c902d8 3c000018 7dd907b4 
> > 7ad2c7e2 7f890000 7c000026 5400fffe <0b000000> e93e8128 3b000000 80090000 
> 
> /* Convert GFP flags to their corresponding migrate type */
> static inline int allocflags_to_migratetype(gfp_t gfp_flags)
> {
>         WARN_ON((gfp_flags & GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
> 
> Mel, Pekka: would you have some head-scratching time for this one please?

What we have is __getblk() -> __getblk_slow() -> grow_buffers() -> 
grow_dev_page() doing find_or_create_page() with __GFP_MOVABLE set. That 
path then eventually does radix_tree_preload -> kmem_cache_alloc() to a 
cache that has SLAB_RECLAIM_ACCOUNT set which implies __GFP_RECLAIMABLE 
(for both SLAB and SLUB). So we oops there.

I suspect the WARN_ON() is bogus although I really don't know that part 
of the code all too well. Mel?

			Pekka

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Mel Gorman]

On (04/03/08 21:18), Pekka Enberg didst pronounce:
> Andrew Morton wrote:
> >> [c000000009edf5f0] [c0000000000b56e4] .__alloc_pages_internal+0xf8/0x470
> >> [c000000009edf6e0] [c0000000000e0458] .kmem_getpages+0x8c/0x194
> >> [c000000009edf770] [c0000000000e1050] .fallback_alloc+0x194/0x254
> >> [c000000009edf820] [c0000000000e14b0] .kmem_cache_alloc+0xd8/0x144
> >> [c000000009edf8c0] [c0000000001fe0f8] .radix_tree_preload+0x50/0xd4
> >> [c000000009edf960] [c0000000000ad048] .add_to_page_cache+0x38/0x12c
> >> [c000000009edfa00] [c0000000000ad158] .add_to_page_cache_lru+0x1c/0x4c
> >> [c000000009edfa90] [c0000000000add58] .find_or_create_page+0x60/0xa8
> >> [c000000009edfb30] [c00000000011e478] .__getblk+0x140/0x310
> >> [c000000009edfc00] [c0000000001b78c4] 
> >.journal_get_descriptor_buffer+0x44/0xd8
> >> [c000000009edfca0] [c0000000001b236c] 
> >.journal_commit_transaction+0x948/0x1590
> >> [c000000009edfe00] [c0000000001b585c] .kjournald+0xf4/0x2ac
> >> [c000000009edff00] [c00000000007ff4c] .kthread+0x84/0xd0
> >> [c000000009edff90] [c000000000028900] .kernel_thread+0x4c/0x68
> >> Instruction dump:
> >> 7dc57378 48009575 60000000 2fa30000 419e0490 56c902d8 3c000018 7dd907b4 
> >> 7ad2c7e2 7f890000 7c000026 5400fffe <0b000000> e93e8128 3b000000 
> >80090000 
> >/* Convert GFP flags to their corresponding migrate type */
> >static inline int allocflags_to_migratetype(gfp_t gfp_flags)
> >{
> >        WARN_ON((gfp_flags & GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
> >
> >Mel, Pekka: would you have some head-scratching time for this one please?
> 
> What we have is __getblk() -> __getblk_slow() -> grow_buffers() -> 
> grow_dev_page() doing find_or_create_page() with __GFP_MOVABLE set. That 
> path then eventually does radix_tree_preload -> kmem_cache_alloc() to a 
> cache that has SLAB_RECLAIM_ACCOUNT set which implies __GFP_RECLAIMABLE 
> (for both SLAB and SLUB). So we oops there.
> 
> I suspect the WARN_ON() is bogus although I really don't know that part 
> of the code all too well. Mel?
> 

The warn-on is valid. A situation should not exist that allows both flags to
be set. I suspect  if remove-set_migrateflags.patch was reverted from -mm
the warning would not trigger. Christoph, would it be reasonable to always
clear __GFP_MOVABLE when __GFP_RECLAIMABLE is set for SLAB_RECLAIM_ACCOUNT.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Pekka Enberg]

(adding Christoph as cc)

On Tue, Mar 4, 2008 at 9:35 PM, Mel Gorman <mel@csn.ul.ie> wrote:
>  > >> [c000000009edf5f0] [c0000000000b56e4] .__alloc_pages_internal+0xf8/0x470
>  > >> [c000000009edf6e0] [c0000000000e0458] .kmem_getpages+0x8c/0x194
>  > >> [c000000009edf770] [c0000000000e1050] .fallback_alloc+0x194/0x254
>  > >> [c000000009edf820] [c0000000000e14b0] .kmem_cache_alloc+0xd8/0x144
>  > >> [c000000009edf8c0] [c0000000001fe0f8] .radix_tree_preload+0x50/0xd4
>  > >> [c000000009edf960] [c0000000000ad048] .add_to_page_cache+0x38/0x12c
>  > >> [c000000009edfa00] [c0000000000ad158] .add_to_page_cache_lru+0x1c/0x4c
>  > >> [c000000009edfa90] [c0000000000add58] .find_or_create_page+0x60/0xa8
>  > >> [c000000009edfb30] [c00000000011e478] .__getblk+0x140/0x310
>  > >> [c000000009edfc00] [c0000000001b78c4]
>  > >.journal_get_descriptor_buffer+0x44/0xd8
>  > >> [c000000009edfca0] [c0000000001b236c]
>  > >.journal_commit_transaction+0x948/0x1590
>  > >> [c000000009edfe00] [c0000000001b585c] .kjournald+0xf4/0x2ac
>  > >> [c000000009edff00] [c00000000007ff4c] .kthread+0x84/0xd0
>  > >> [c000000009edff90] [c000000000028900] .kernel_thread+0x4c/0x68
>  > >> Instruction dump:
>  > >> 7dc57378 48009575 60000000 2fa30000 419e0490 56c902d8 3c000018 7dd907b4
>  > >> 7ad2c7e2 7f890000 7c000026 5400fffe <0b000000> e93e8128 3b000000
>  > >80090000
>  > >/* Convert GFP flags to their corresponding migrate type */
>  > >static inline int allocflags_to_migratetype(gfp_t gfp_flags)
>  > >{
>  > >        WARN_ON((gfp_flags & GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
>  > >
>  > >Mel, Pekka: would you have some head-scratching time for this one please?
>  >
>  > What we have is __getblk() -> __getblk_slow() -> grow_buffers() ->
>  > grow_dev_page() doing find_or_create_page() with __GFP_MOVABLE set. That
>  > path then eventually does radix_tree_preload -> kmem_cache_alloc() to a
>  > cache that has SLAB_RECLAIM_ACCOUNT set which implies __GFP_RECLAIMABLE
>  > (for both SLAB and SLUB). So we oops there.
>  >
>  > I suspect the WARN_ON() is bogus although I really don't know that part
>  > of the code all too well. Mel?
>  >
>
>  The warn-on is valid. A situation should not exist that allows both flags to
>  be set. I suspect  if remove-set_migrateflags.patch was reverted from -mm
>  the warning would not trigger. Christoph, would it be reasonable to always
>  clear __GFP_MOVABLE when __GFP_RECLAIMABLE is set for SLAB_RECLAIM_ACCOUNT.
>
>  --
>  Mel Gorman
>  Part-time Phd Student                          Linux Technology Center
>  University of Limerick                         IBM Dublin Software Lab
>
>
>
>  --
>  To unsubscribe, send a message with 'unsubscribe linux-mm' in
>  the body to majordomo@kvack.org.  For more info on Linux MM,
>  see: http://www.linux-mm.org/ .
>  Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Christoph Lameter]

On Tue, 4 Mar 2008, Pekka Enberg wrote:

> >  > I suspect the WARN_ON() is bogus although I really don't know that part
> >  > of the code all too well. Mel?
> >  >
> >
> >  The warn-on is valid. A situation should not exist that allows both flags to
> >  be set. I suspect  if remove-set_migrateflags.patch was reverted from -mm
> >  the warning would not trigger. Christoph, would it be reasonable to always
> >  clear __GFP_MOVABLE when __GFP_RECLAIMABLE is set for SLAB_RECLAIM_ACCOUNT.

Slab allocations should never be passed these flags since the slabs do 
their own thing there.

The following patch would clear these in slub:

---
 mm/slub.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.25-rc3-mm1/mm/slub.c
===================================================================
--- linux-2.6.25-rc3-mm1.orig/mm/slub.c	2008-03-04 11:53:47.600342756 -0800
+++ linux-2.6.25-rc3-mm1/mm/slub.c	2008-03-04 11:55:40.153855150 -0800
@@ -1033,8 +1033,8 @@ static struct page *allocate_slab(struct
 	struct page *page;
 	int pages = 1 << s->order;
 
+	flags &= ~GFP_MOVABLE_MASK;
 	flags |= s->allocflags;
-
 	page = alloc_slab_page(flags | __GFP_NOWARN | __GFP_NORETRY,
 								node, s->order);
 	if (unlikely(!page)) {

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Pekka J Enberg]

On Tue, 4 Mar 2008, Christoph Lameter wrote:
> Slab allocations should never be passed these flags since the slabs do 
> their own thing there.
> 
> The following patch would clear these in slub:

Here's the same fix for SLAB:
 
diff --git a/mm/slab.c b/mm/slab.c
index 473e6c2..c6dbf7e 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1677,6 +1677,7 @@ static void *kmem_getpages(struct kmem_cache *cachep, gfp_t flags, int nodeid)
 	flags |= __GFP_COMP;
 #endif
 
+	flags &= ~GFP_MOVABLE_MASK;
 	flags |= cachep->gfpflags;
 	if (cachep->flags & SLAB_RECLAIM_ACCOUNT)
 		flags |= __GFP_RECLAIMABLE;

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Christoph Lameter]

On Tue, 4 Mar 2008, Pekka J Enberg wrote:

> On Tue, 4 Mar 2008, Christoph Lameter wrote:
> > Slab allocations should never be passed these flags since the slabs do 
> > their own thing there.
> > 
> > The following patch would clear these in slub:
> 
> Here's the same fix for SLAB:

That is an immediate fix ok. But there must be some location where SLAB 
does the masking of the gfp bits where things go wrong. Looking for that.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Christoph Lameter]

I think this is the correct fix.

The NUMA fallback logic should be passing local_flags to kmem_get_pages() 
and not simply the flags.

Maybe a stable candidate since we are now simply 
passing on flags to the page allocator on the fallback path.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

---
 mm/slab.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.25-rc3-mm1/mm/slab.c
===================================================================
--- linux-2.6.25-rc3-mm1.orig/mm/slab.c	2008-03-04 12:01:07.430911920 -0800
+++ linux-2.6.25-rc3-mm1/mm/slab.c	2008-03-04 12:04:54.449857145 -0800
@@ -3277,7 +3277,7 @@ retry:
 		if (local_flags & __GFP_WAIT)
 			local_irq_enable();
 		kmem_flagcheck(cache, flags);
-		obj = kmem_getpages(cache, flags, -1);
+		obj = kmem_getpages(cache, local_flags, -1);
 		if (local_flags & __GFP_WAIT)
 			local_irq_disable();
 		if (obj) {

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Pekka Enberg]

Christoph Lameter wrote:
> I think this is the correct fix.
> 
> The NUMA fallback logic should be passing local_flags to kmem_get_pages() 
> and not simply the flags.
> 
> Maybe a stable candidate since we are now simply 
> passing on flags to the page allocator on the fallback path.
> 
> Signed-off-by: Christoph Lameter <clameter@sgi.com>

Indeed, good catch. I spotted the same thing just few seconds ago.

Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>

Was it you Kamalesh that reported this? Can you please re-test?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Kamalesh Babulal]

Pekka Enberg wrote:
> Christoph Lameter wrote:
>> I think this is the correct fix.
>>
>> The NUMA fallback logic should be passing local_flags to kmem_get_pages() 
>> and not simply the flags.
>>
>> Maybe a stable candidate since we are now simply 
>> passing on flags to the page allocator on the fallback path.
>>
>> Signed-off-by: Christoph Lameter <clameter@sgi.com>
> 
> Indeed, good catch. I spotted the same thing just few seconds ago.
> 
> Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>
> 
> Was it you Kamalesh that reported this? Can you please re-test?

Thanks the patch fixes the kernel bug.

Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Andrew Morton]

On Tue, 4 Mar 2008 12:07:39 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:

> I think this is the correct fix.
> 
> The NUMA fallback logic should be passing local_flags to kmem_get_pages() 
> and not simply the flags.
> 
> Maybe a stable candidate since we are now simply 
> passing on flags to the page allocator on the fallback path.

Do we know why this is only reported in 2.6.25-rc3-mm1?

Why does this need fixing in 2.6.24.x?

Thanks.

> Signed-off-by: Christoph Lameter <clameter@sgi.com>
> 
> ---
>  mm/slab.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6.25-rc3-mm1/mm/slab.c
> ===================================================================
> --- linux-2.6.25-rc3-mm1.orig/mm/slab.c	2008-03-04 12:01:07.430911920 -0800
> +++ linux-2.6.25-rc3-mm1/mm/slab.c	2008-03-04 12:04:54.449857145 -0800
> @@ -3277,7 +3277,7 @@ retry:
>  		if (local_flags & __GFP_WAIT)
>  			local_irq_enable();
>  		kmem_flagcheck(cache, flags);
> -		obj = kmem_getpages(cache, flags, -1);
> +		obj = kmem_getpages(cache, local_flags, -1);
>  		if (local_flags & __GFP_WAIT)
>  			local_irq_disable();
>  		if (obj) {

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Pekka Enberg]

Andrew Morton wrote:
> On Tue, 4 Mar 2008 12:07:39 -0800 (PST)
> Christoph Lameter <clameter@sgi.com> wrote:
> 
>> I think this is the correct fix.
>>
>> The NUMA fallback logic should be passing local_flags to kmem_get_pages() 
>> and not simply the flags.
>>
>> Maybe a stable candidate since we are now simply 
>> passing on flags to the page allocator on the fallback path.
> 
> Do we know why this is only reported in 2.6.25-rc3-mm1?
> 
> Why does this need fixing in 2.6.24.x?

Looking at the code, it's triggerable in 2.6.24.3 at least. Why we don't 
have a report yet, probably because (1) the default allocator is SLUB 
which doesn't suffer from this and (2) you need a big honkin' NUMA box 
that causes fallback allocations to happen to trigger it.

			Pekka

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Christoph Lameter]

On Tue, 4 Mar 2008, Pekka Enberg wrote:

> Looking at the code, it's triggerable in 2.6.24.3 at least. Why we don't have
> a report yet, probably because (1) the default allocator is SLUB which doesn't
> suffer from this and (2) you need a big honkin' NUMA box that causes fallback
> allocations to happen to trigger it.

Plus the issue only became a problem after the antifrag stuff went in. 
That came with SLUB as the default.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Mel Gorman]

On (04/03/08 12:34), Andrew Morton didst pronounce:
> On Tue, 4 Mar 2008 12:07:39 -0800 (PST)
> Christoph Lameter <clameter@sgi.com> wrote:
> 
> > I think this is the correct fix.
> > 
> > The NUMA fallback logic should be passing local_flags to kmem_get_pages() 
> > and not simply the flags.
> > 
> > Maybe a stable candidate since we are now simply 
> > passing on flags to the page allocator on the fallback path.
> 
> Do we know why this is only reported in 2.6.25-rc3-mm1?
> 
> Why does this need fixing in 2.6.24.x?
> 

I don't believe it needs to be fixed in 2.6.24.3. The call-sites in
lib/radix-tree.c there look like

        ret = kmem_cache_alloc(radix_tree_node_cachep,
                                set_migrateflags(gfp_mask, __GFP_RECLAIMABLE));

        node = kmem_cache_alloc(radix_tree_node_cachep,
                               set_migrateflags(gfp_mask, __GFP_RECLAIMABLE));

and set_migrateflags() looks like

#define GFP_MOVABLE_MASK (__GFP_RECLAIMABLE|__GFP_MOVABLE)
static inline gfp_t set_migrateflags(gfp_t gfp, gfp_t migrate_flags)
{
        BUG_ON((gfp & GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
        return (gfp & ~(GFP_MOVABLE_MASK)) | migrate_flags;
}

so the flags were already getting cleared and the WARN_ON could not
trigger in this path. In 2.6.25-rc3-mm1, the patch
remove-set_migrateflags.patch gets rid of set_migateflags()
which led to this situation.

The surprise is that it didn't get caught in an earlier -mm but it could
be because it only affected slab.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Mel Gorman]

On (04/03/08 12:07), Christoph Lameter didst pronounce:
> I think this is the correct fix.
> 
> The NUMA fallback logic should be passing local_flags to kmem_get_pages() 
> and not simply the flags.
> 
> Maybe a stable candidate since we are now simply 
> passing on flags to the page allocator on the fallback path.
> 
> Signed-off-by: Christoph Lameter <clameter@sgi.com>

Acked-by: Mel Gorman <mel@csn.ul.ie>

Thanks Christoph.

> 
> ---
>  mm/slab.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6.25-rc3-mm1/mm/slab.c
> ===================================================================
> --- linux-2.6.25-rc3-mm1.orig/mm/slab.c	2008-03-04 12:01:07.430911920 -0800
> +++ linux-2.6.25-rc3-mm1/mm/slab.c	2008-03-04 12:04:54.449857145 -0800
> @@ -3277,7 +3277,7 @@ retry:
>  		if (local_flags & __GFP_WAIT)
>  			local_irq_enable();
>  		kmem_flagcheck(cache, flags);
> -		obj = kmem_getpages(cache, flags, -1);
> +		obj = kmem_getpages(cache, local_flags, -1);
>  		if (local_flags & __GFP_WAIT)
>  			local_irq_disable();
>  		if (obj) {
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Christoph Lameter]

On Tue, 4 Mar 2008, Pekka Enberg wrote:

> >  > >> [c000000009edf5f0] [c0000000000b56e4] .__alloc_pages_internal+0xf8/0x470
> >  > >> [c000000009edf6e0] [c0000000000e0458] .kmem_getpages+0x8c/0x194
> >  > >> [c000000009edf770] [c0000000000e1050] .fallback_alloc+0x194/0x254
> >  > >> [c000000009edf820] [c0000000000e14b0] .kmem_cache_alloc+0xd8/0x144

Ahh! This is SLAB. slub does not suffer this problem since new_slab() 
masks the bits correctly.

So we need to fix SLAB.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>