* mm: kernel BUG at mm/mempolicy.c:1203! @ 2013-12-15 23:37 Sasha Levin 2013-12-16 0:26 ` Andrew Morton 2013-12-17 0:44 ` Bob Liu 0 siblings, 2 replies; 10+ messages in thread From: Sasha Levin @ 2013-12-15 23:37 UTC (permalink / raw) To: Andrew Morton, Naoya Horiguchi; +Cc: linux-mm@kvack.org, dan.carpenter Hi all, While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've stumbled on the following spew. This seems to be due to commit 0bf598d863e "mbind: add BUG_ON(!vma) in new_vma_page()" which added that BUG_ON. [ 538.836802] kernel BUG at mm/mempolicy.c:1203! [ 538.838245] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 538.838507] Dumping ftrace buffer: [ 538.840150] (ftrace buffer empty) [ 538.840150] Modules linked in: [ 538.840256] CPU: 15 PID: 21136 Comm: trinity-child96 Tainted: G W 3.13.0-rc 3-next-20131213-sasha-00010-g6749b49-dirty #4104 [ 538.840256] task: ffff880e73288000 ti: ffff880e73290000 task.ti: ffff880e73290000 [ 538.840256] RIP: 0010:[<ffffffff812a4092>] [<ffffffff812a4092>] new_vma_page+0x52/0x b0 [ 538.840256] RSP: 0000:ffff880e73291d38 EFLAGS: 00010246 [ 538.840256] RAX: fffffffffffffff2 RBX: 0000000000000000 RCX: 0000000000000000 [ 538.840256] RDX: 0000000008040075 RSI: ffff880dc59ebe00 RDI: ffffea003e017c00 [ 538.840256] RBP: ffff880e73291d58 R08: 0000000000000002 R09: 0000000000000001 [ 538.840256] R10: 0000000000000001 R11: 0000000000000000 R12: fffffffffffffff2 [ 538.840256] R13: ffffea003e017c00 R14: 0000000000000002 R15: 00000000fffffff4 [ 538.840256] FS: 00007f43832a3700(0000) GS:ffff880fe7400000(0000) knlGS:0000000000000 000 [ 538.840256] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 538.840256] CR2: 0000000002083be8 CR3: 0000000ec894e000 CR4: 00000000000006e0 [ 538.840256] Stack: [ 538.840256] 0000000000000000 ffffea003e017c00 0000000000000000 ffff880e73291e58 [ 538.840256] ffff880e73291da8 ffffffff812b5664 000000000000044e 0000000000000000 [ 538.840256] ffff880e73291da8 ffffea003e017c00 ffffea003e017c40 ffff880e73291e58 [ 538.840256] Call Trace: [ 538.840256] [<ffffffff812b5664>] unmap_and_move+0x44/0x180 [ 538.840256] [<ffffffff812b588b>] migrate_pages+0xeb/0x2f0 [ 538.840256] [<ffffffff812a4040>] ? alloc_pages_vma+0x220/0x220 [ 538.840256] [<ffffffff812a4ba3>] do_mbind+0x283/0x340 [ 538.840256] [<ffffffff812794af>] ? might_fault+0x9f/0xb0 [ 538.840256] [<ffffffff81279466>] ? might_fault+0x56/0xb0 [ 538.840256] [<ffffffff81249a98>] ? context_tracking_user_exit+0xb8/0x1d0 [ 538.840256] [<ffffffff812a4ce9>] SYSC_mbind+0x89/0xb0 [ 538.840256] [<ffffffff81249b75>] ? context_tracking_user_exit+0x195/0x1d0 [ 538.840256] [<ffffffff812a4d1e>] SyS_mbind+0xe/0x10 [ 538.840256] [<ffffffff843bc489>] ia32_do_call+0x13/0x13 [ 538.840256] Code: 95 58 fe ff 49 89 c4 48 83 f8 f2 75 14 48 8b 5b 10 48 85 db 75 e3 0f 1f 00 eb 10 66 0f 1f 44 00 00 48 85 db 0f 1f 44 00 00 75 0e <0f> 0b 0f 1f 40 00 eb fe 66 0f 1f 44 00 00 4c 89 ef e8 68 6a ff [ 538.840256] RIP [<ffffffff812a4092>] new_vma_page+0x52/0xb0 [ 538.840256] RSP <ffff880e73291d38> Thanks, Sasha -- 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> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/mempolicy.c:1203! 2013-12-15 23:37 mm: kernel BUG at mm/mempolicy.c:1203! Sasha Levin @ 2013-12-16 0:26 ` Andrew Morton 2013-12-17 0:44 ` Bob Liu 1 sibling, 0 replies; 10+ messages in thread From: Andrew Morton @ 2013-12-16 0:26 UTC (permalink / raw) To: Sasha Levin Cc: Naoya Horiguchi, linux-mm@kvack.org, dan.carpenter, Dave Jones On Sun, 15 Dec 2013 18:37:41 -0500 Sasha Levin <sasha.levin@oracle.com> wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've > stumbled on the following spew. > > This seems to be due to commit 0bf598d863e "mbind: add BUG_ON(!vma) in new_vma_page()" > which added that BUG_ON. > > [ 538.836802] kernel BUG at mm/mempolicy.c:1203! > [ 538.838245] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 538.838507] Dumping ftrace buffer: > [ 538.840150] (ftrace buffer empty) > [ 538.840150] Modules linked in: > [ 538.840256] CPU: 15 PID: 21136 Comm: trinity-child96 Tainted: G W 3.13.0-rc > 3-next-20131213-sasha-00010-g6749b49-dirty #4104 > [ 538.840256] task: ffff880e73288000 ti: ffff880e73290000 task.ti: ffff880e73290000 > [ 538.840256] RIP: 0010:[<ffffffff812a4092>] [<ffffffff812a4092>] new_vma_page+0x52/0x > b0 > [ 538.840256] RSP: 0000:ffff880e73291d38 EFLAGS: 00010246 > [ 538.840256] RAX: fffffffffffffff2 RBX: 0000000000000000 RCX: 0000000000000000 > [ 538.840256] RDX: 0000000008040075 RSI: ffff880dc59ebe00 RDI: ffffea003e017c00 > [ 538.840256] RBP: ffff880e73291d58 R08: 0000000000000002 R09: 0000000000000001 > [ 538.840256] R10: 0000000000000001 R11: 0000000000000000 R12: fffffffffffffff2 > [ 538.840256] R13: ffffea003e017c00 R14: 0000000000000002 R15: 00000000fffffff4 > [ 538.840256] FS: 00007f43832a3700(0000) GS:ffff880fe7400000(0000) knlGS:0000000000000 > 000 > [ 538.840256] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 538.840256] CR2: 0000000002083be8 CR3: 0000000ec894e000 CR4: 00000000000006e0 > [ 538.840256] Stack: > [ 538.840256] 0000000000000000 ffffea003e017c00 0000000000000000 ffff880e73291e58 > [ 538.840256] ffff880e73291da8 ffffffff812b5664 000000000000044e 0000000000000000 > [ 538.840256] ffff880e73291da8 ffffea003e017c00 ffffea003e017c40 ffff880e73291e58 > [ 538.840256] Call Trace: > [ 538.840256] [<ffffffff812b5664>] unmap_and_move+0x44/0x180 > [ 538.840256] [<ffffffff812b588b>] migrate_pages+0xeb/0x2f0 > [ 538.840256] [<ffffffff812a4040>] ? alloc_pages_vma+0x220/0x220 > [ 538.840256] [<ffffffff812a4ba3>] do_mbind+0x283/0x340 > [ 538.840256] [<ffffffff812794af>] ? might_fault+0x9f/0xb0 > [ 538.840256] [<ffffffff81279466>] ? might_fault+0x56/0xb0 > [ 538.840256] [<ffffffff81249a98>] ? context_tracking_user_exit+0xb8/0x1d0 > [ 538.840256] [<ffffffff812a4ce9>] SYSC_mbind+0x89/0xb0 > [ 538.840256] [<ffffffff81249b75>] ? context_tracking_user_exit+0x195/0x1d0 > [ 538.840256] [<ffffffff812a4d1e>] SyS_mbind+0xe/0x10 > [ 538.840256] [<ffffffff843bc489>] ia32_do_call+0x13/0x13 > [ 538.840256] Code: 95 58 fe ff 49 89 c4 48 83 f8 f2 75 14 48 8b 5b 10 48 85 db 75 e3 0f 1f 00 eb > 10 66 0f 1f 44 00 00 48 85 db 0f 1f 44 00 00 75 0e <0f> 0b 0f 1f 40 00 eb fe 66 0f 1f 44 00 00 4c 89 > ef e8 68 6a ff > [ 538.840256] RIP [<ffffffff812a4092>] new_vma_page+0x52/0xb0 > [ 538.840256] RSP <ffff880e73291d38> Davej reported this as well. I don't see how we can make this assertion - queue_pages_range() walks off the end of the vma list, returns NULL and boom? btw, perhaps it would be useful if the fuzzer were to generate a log of the syscalls it is performing so people could replay them to reproduce the bug? Not easy when it's a multi-threaded thing I guess.. -- 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> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/mempolicy.c:1203! 2013-12-15 23:37 mm: kernel BUG at mm/mempolicy.c:1203! Sasha Levin 2013-12-16 0:26 ` Andrew Morton @ 2013-12-17 0:44 ` Bob Liu 2013-12-17 1:10 ` Sasha Levin 1 sibling, 1 reply; 10+ messages in thread From: Bob Liu @ 2013-12-17 0:44 UTC (permalink / raw) To: Sasha Levin Cc: Andrew Morton, Naoya Horiguchi, linux-mm@kvack.org, dan.carpenter On 12/16/2013 07:37 AM, Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest running latest -next > kernel, I've > stumbled on the following spew. > > This seems to be due to commit 0bf598d863e "mbind: add BUG_ON(!vma) in > new_vma_page()" > which added that BUG_ON. Could you take a try with this patch from Wanpeng Li? Thanks, -Bob Subject: [PATCH] mm/mempolicy: fix !vma in new_vma_page() .... Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com> index eca4a31..73b5a35 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -1197,14 +1197,16 @@ static struct page *new_vma_page(struct page *page, unsigned long private, int * break; vma = vma->vm_next; } + + if (PageHuge(page)) { + if (vma) + return alloc_huge_page_noerr(vma, address, 1); + else + return NULL; + } /* - * queue_pages_range() confirms that @page belongs to some vma, - * so vma shouldn't be NULL. + * if !vma, alloc_page_vma() will use task or system default policy */ - BUG_ON(!vma); - - if (PageHuge(page)) - return alloc_huge_page_noerr(vma, address, 1); return alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, address); } #else -- 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> ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/mempolicy.c:1203! 2013-12-17 0:44 ` Bob Liu @ 2013-12-17 1:10 ` Sasha Levin 2013-12-17 4:38 ` Bob Liu 0 siblings, 1 reply; 10+ messages in thread From: Sasha Levin @ 2013-12-17 1:10 UTC (permalink / raw) To: Bob Liu; +Cc: Andrew Morton, Naoya Horiguchi, linux-mm@kvack.org, dan.carpenter On 12/16/2013 07:44 PM, Bob Liu wrote: > > On 12/16/2013 07:37 AM, Sasha Levin wrote: >> Hi all, >> >> While fuzzing with trinity inside a KVM tools guest running latest -next >> kernel, I've >> stumbled on the following spew. >> >> This seems to be due to commit 0bf598d863e "mbind: add BUG_ON(!vma) in >> new_vma_page()" >> which added that BUG_ON. > > Could you take a try with this patch from Wanpeng Li? > > Thanks, > -Bob > > Subject: [PATCH] mm/mempolicy: fix !vma in new_vma_page() > .... > Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com> > index eca4a31..73b5a35 100644 > --- a/mm/mempolicy.c > +++ b/mm/mempolicy.c > @@ -1197,14 +1197,16 @@ static struct page *new_vma_page(struct page > *page, unsigned long private, int * > break; > vma = vma->vm_next; > } > + > + if (PageHuge(page)) { > + if (vma) > + return alloc_huge_page_noerr(vma, address, 1); > + else > + return NULL; > + } > /* > - * queue_pages_range() confirms that @page belongs to some vma, > - * so vma shouldn't be NULL. > + * if !vma, alloc_page_vma() will use task or system default policy > */ > - BUG_ON(!vma); > - > - if (PageHuge(page)) > - return alloc_huge_page_noerr(vma, address, 1); > return alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, address); > } > #else > Hmm... So in essence it's mostly a revert of Naoya's patch, who seemed pretty certain that this situation shouldn't happen at all. What's the reasoning behind just reverting that? Thanks, Sasha -- 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> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/mempolicy.c:1203! 2013-12-17 1:10 ` Sasha Levin @ 2013-12-17 4:38 ` Bob Liu 2013-12-17 6:11 ` Naoya Horiguchi 0 siblings, 1 reply; 10+ messages in thread From: Bob Liu @ 2013-12-17 4:38 UTC (permalink / raw) To: Sasha Levin Cc: Andrew Morton, Naoya Horiguchi, linux-mm@kvack.org, dan.carpenter On 12/17/2013 09:10 AM, Sasha Levin wrote: > On 12/16/2013 07:44 PM, Bob Liu wrote: >> >> On 12/16/2013 07:37 AM, Sasha Levin wrote: >>> Hi all, >>> >>> While fuzzing with trinity inside a KVM tools guest running latest -next >>> kernel, I've >>> stumbled on the following spew. >>> >>> This seems to be due to commit 0bf598d863e "mbind: add BUG_ON(!vma) in >>> new_vma_page()" >>> which added that BUG_ON. >> >> Could you take a try with this patch from Wanpeng Li? >> >> Thanks, >> -Bob >> >> Subject: [PATCH] mm/mempolicy: fix !vma in new_vma_page() >> .... >> Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com> >> index eca4a31..73b5a35 100644 >> --- a/mm/mempolicy.c >> +++ b/mm/mempolicy.c >> @@ -1197,14 +1197,16 @@ static struct page *new_vma_page(struct page >> *page, unsigned long private, int * >> break; >> vma = vma->vm_next; >> } >> + >> + if (PageHuge(page)) { >> + if (vma) >> + return alloc_huge_page_noerr(vma, address, 1); >> + else >> + return NULL; >> + } >> /* >> - * queue_pages_range() confirms that @page belongs to some vma, >> - * so vma shouldn't be NULL. >> + * if !vma, alloc_page_vma() will use task or system default policy >> */ >> - BUG_ON(!vma); >> - >> - if (PageHuge(page)) >> - return alloc_huge_page_noerr(vma, address, 1); >> return alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, address); >> } >> #else >> > > Hmm... So in essence it's mostly a revert of Naoya's patch, who seemed > pretty certain that this > situation shouldn't happen at all. What's the reasoning behind just I think this assumption may not correct. Even if address = __vma_address(page, vma); and vma->start < address < vma->end; page_address_in_vma() may still return -EFAULT because of many other conditions in it. As a result the while loop in new_vma_page() may end with vma=NULL. Naoya, any idea? -- Regards, -Bob -- 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> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/mempolicy.c:1203! 2013-12-17 4:38 ` Bob Liu @ 2013-12-17 6:11 ` Naoya Horiguchi 2013-12-17 6:23 ` Wanpeng Li 2013-12-17 6:46 ` Sasha Levin 0 siblings, 2 replies; 10+ messages in thread From: Naoya Horiguchi @ 2013-12-17 6:11 UTC (permalink / raw) To: Bob Liu; +Cc: Sasha Levin, Andrew Morton, linux-mm@kvack.org, dan.carpenter Hello Bob, On Tue, Dec 17, 2013 at 12:38:49PM +0800, Bob Liu wrote: > On 12/17/2013 09:10 AM, Sasha Levin wrote: > > On 12/16/2013 07:44 PM, Bob Liu wrote: > >> > >> On 12/16/2013 07:37 AM, Sasha Levin wrote: > >>> Hi all, > >>> > >>> While fuzzing with trinity inside a KVM tools guest running latest -next > >>> kernel, I've > >>> stumbled on the following spew. > >>> > >>> This seems to be due to commit 0bf598d863e "mbind: add BUG_ON(!vma) in > >>> new_vma_page()" > >>> which added that BUG_ON. > >> > >> Could you take a try with this patch from Wanpeng Li? > >> > >> Thanks, > >> -Bob > >> > >> Subject: [PATCH] mm/mempolicy: fix !vma in new_vma_page() > >> .... > >> Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com> > >> index eca4a31..73b5a35 100644 > >> --- a/mm/mempolicy.c > >> +++ b/mm/mempolicy.c > >> @@ -1197,14 +1197,16 @@ static struct page *new_vma_page(struct page > >> *page, unsigned long private, int * > >> break; > >> vma = vma->vm_next; > >> } > >> + > >> + if (PageHuge(page)) { > >> + if (vma) > >> + return alloc_huge_page_noerr(vma, address, 1); > >> + else > >> + return NULL; > >> + } > >> /* > >> - * queue_pages_range() confirms that @page belongs to some vma, > >> - * so vma shouldn't be NULL. > >> + * if !vma, alloc_page_vma() will use task or system default policy > >> */ > >> - BUG_ON(!vma); > >> - > >> - if (PageHuge(page)) > >> - return alloc_huge_page_noerr(vma, address, 1); > >> return alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, address); > >> } > >> #else > >> > > > > Hmm... So in essence it's mostly a revert of Naoya's patch, who seemed > > pretty certain that this > > situation shouldn't happen at all. What's the reasoning behind just > > I think this assumption may not correct. > Even if > address = __vma_address(page, vma); > and > vma->start < address < vma->end; > page_address_in_vma() may still return -EFAULT because of many other > conditions in it. > As a result the while loop in new_vma_page() may end with vma=NULL. > > Naoya, any idea? Yes, you totally make sense. So please apply Wanpeng's patch. Thanks, Naoya Horiguchi -- 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> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/mempolicy.c:1203! 2013-12-17 6:11 ` Naoya Horiguchi @ 2013-12-17 6:23 ` Wanpeng Li 2013-12-17 6:46 ` Sasha Levin 1 sibling, 0 replies; 10+ messages in thread From: Wanpeng Li @ 2013-12-17 6:23 UTC (permalink / raw) To: Naoya Horiguchi Cc: Bob Liu, Sasha Levin, Andrew Morton, linux-mm@kvack.org, dan.carpenter On Tue, Dec 17, 2013 at 01:11:23AM -0500, Naoya Horiguchi wrote: >Hello Bob, > >On Tue, Dec 17, 2013 at 12:38:49PM +0800, Bob Liu wrote: >> On 12/17/2013 09:10 AM, Sasha Levin wrote: >> > On 12/16/2013 07:44 PM, Bob Liu wrote: >> >> >> >> On 12/16/2013 07:37 AM, Sasha Levin wrote: >> >>> Hi all, >> >>> >> >>> While fuzzing with trinity inside a KVM tools guest running latest -next >> >>> kernel, I've >> >>> stumbled on the following spew. >> >>> >> >>> This seems to be due to commit 0bf598d863e "mbind: add BUG_ON(!vma) in >> >>> new_vma_page()" >> >>> which added that BUG_ON. >> >> >> >> Could you take a try with this patch from Wanpeng Li? >> >> >> >> Thanks, >> >> -Bob >> >> >> >> Subject: [PATCH] mm/mempolicy: fix !vma in new_vma_page() >> >> .... >> >> Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com> >> >> index eca4a31..73b5a35 100644 >> >> --- a/mm/mempolicy.c >> >> +++ b/mm/mempolicy.c >> >> @@ -1197,14 +1197,16 @@ static struct page *new_vma_page(struct page >> >> *page, unsigned long private, int * >> >> break; >> >> vma = vma->vm_next; >> >> } >> >> + >> >> + if (PageHuge(page)) { >> >> + if (vma) >> >> + return alloc_huge_page_noerr(vma, address, 1); >> >> + else >> >> + return NULL; >> >> + } >> >> /* >> >> - * queue_pages_range() confirms that @page belongs to some vma, >> >> - * so vma shouldn't be NULL. >> >> + * if !vma, alloc_page_vma() will use task or system default policy >> >> */ >> >> - BUG_ON(!vma); >> >> - >> >> - if (PageHuge(page)) >> >> - return alloc_huge_page_noerr(vma, address, 1); >> >> return alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, address); >> >> } >> >> #else >> >> >> > >> > Hmm... So in essence it's mostly a revert of Naoya's patch, who seemed >> > pretty certain that this >> > situation shouldn't happen at all. What's the reasoning behind just >> >> I think this assumption may not correct. >> Even if >> address = __vma_address(page, vma); >> and >> vma->start < address < vma->end; >> page_address_in_vma() may still return -EFAULT because of many other >> conditions in it. >> As a result the while loop in new_vma_page() may end with vma=NULL. >> >> Naoya, any idea? > >Yes, you totally make sense. So please apply Wanpeng's patch. > Ah, ok, I will send a formalized patch. Regards, Wanpeng Li >Thanks, >Naoya Horiguchi > >-- >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> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/mempolicy.c:1203! 2013-12-17 6:11 ` Naoya Horiguchi 2013-12-17 6:23 ` Wanpeng Li @ 2013-12-17 6:46 ` Sasha Levin 2013-12-17 6:55 ` Wanpeng Li [not found] ` <20131217065518.GA29118@hacker.(null)> 1 sibling, 2 replies; 10+ messages in thread From: Sasha Levin @ 2013-12-17 6:46 UTC (permalink / raw) To: Naoya Horiguchi, Bob Liu; +Cc: Andrew Morton, linux-mm@kvack.org, dan.carpenter On 12/17/2013 01:11 AM, Naoya Horiguchi wrote: > Hello Bob, > > On Tue, Dec 17, 2013 at 12:38:49PM +0800, Bob Liu wrote: >> On 12/17/2013 09:10 AM, Sasha Levin wrote: >>> On 12/16/2013 07:44 PM, Bob Liu wrote: >>>> >>>> On 12/16/2013 07:37 AM, Sasha Levin wrote: >>>>> Hi all, >>>>> >>>>> While fuzzing with trinity inside a KVM tools guest running latest -next >>>>> kernel, I've >>>>> stumbled on the following spew. >>>>> >>>>> This seems to be due to commit 0bf598d863e "mbind: add BUG_ON(!vma) in >>>>> new_vma_page()" >>>>> which added that BUG_ON. >>>> >>>> Could you take a try with this patch from Wanpeng Li? >>>> >>>> Thanks, >>>> -Bob >>>> >>>> Subject: [PATCH] mm/mempolicy: fix !vma in new_vma_page() >>>> .... >>>> Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com> >>>> index eca4a31..73b5a35 100644 >>>> --- a/mm/mempolicy.c >>>> +++ b/mm/mempolicy.c >>>> @@ -1197,14 +1197,16 @@ static struct page *new_vma_page(struct page >>>> *page, unsigned long private, int * >>>> break; >>>> vma = vma->vm_next; >>>> } >>>> + >>>> + if (PageHuge(page)) { >>>> + if (vma) >>>> + return alloc_huge_page_noerr(vma, address, 1); >>>> + else >>>> + return NULL; >>>> + } >>>> /* >>>> - * queue_pages_range() confirms that @page belongs to some vma, >>>> - * so vma shouldn't be NULL. >>>> + * if !vma, alloc_page_vma() will use task or system default policy >>>> */ >>>> - BUG_ON(!vma); >>>> - >>>> - if (PageHuge(page)) >>>> - return alloc_huge_page_noerr(vma, address, 1); >>>> return alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, address); >>>> } >>>> #else >>>> >>> >>> Hmm... So in essence it's mostly a revert of Naoya's patch, who seemed >>> pretty certain that this >>> situation shouldn't happen at all. What's the reasoning behind just >> >> I think this assumption may not correct. >> Even if >> address = __vma_address(page, vma); >> and >> vma->start < address < vma->end; >> page_address_in_vma() may still return -EFAULT because of many other >> conditions in it. >> As a result the while loop in new_vma_page() may end with vma=NULL. >> >> Naoya, any idea? > > Yes, you totally make sense. So please apply Wanpeng's patch. Shouldn't it just be a revert of Naoya's patch? Otherwise we're changing code paths unnecessarily. Thanks, Sasha -- 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> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mm: kernel BUG at mm/mempolicy.c:1203! 2013-12-17 6:46 ` Sasha Levin @ 2013-12-17 6:55 ` Wanpeng Li [not found] ` <20131217065518.GA29118@hacker.(null)> 1 sibling, 0 replies; 10+ messages in thread From: Wanpeng Li @ 2013-12-17 6:55 UTC (permalink / raw) To: Sasha Levin Cc: Naoya Horiguchi, Bob Liu, Andrew Morton, linux-mm@kvack.org, dan.carpenter Hi Sasha, On Tue, Dec 17, 2013 at 01:46:42AM -0500, Sasha Levin wrote: >On 12/17/2013 01:11 AM, Naoya Horiguchi wrote: >> Hello Bob, >> >> On Tue, Dec 17, 2013 at 12:38:49PM +0800, Bob Liu wrote: >>> On 12/17/2013 09:10 AM, Sasha Levin wrote: >>>> On 12/16/2013 07:44 PM, Bob Liu wrote: >>>>> >>>>> On 12/16/2013 07:37 AM, Sasha Levin wrote: >>>>>> Hi all, >>>>>> >>>>>> While fuzzing with trinity inside a KVM tools guest running latest -next >>>>>> kernel, I've >>>>>> stumbled on the following spew. >>>>>> >>>>>> This seems to be due to commit 0bf598d863e "mbind: add BUG_ON(!vma) in >>>>>> new_vma_page()" >>>>>> which added that BUG_ON. >>>>> >>>>> Could you take a try with this patch from Wanpeng Li? >>>>> >>>>> Thanks, >>>>> -Bob >>>>> >>>>> Subject: [PATCH] mm/mempolicy: fix !vma in new_vma_page() >>>>> .... >>>>> Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com> >>>>> index eca4a31..73b5a35 100644 >>>>> --- a/mm/mempolicy.c >>>>> +++ b/mm/mempolicy.c >>>>> @@ -1197,14 +1197,16 @@ static struct page *new_vma_page(struct page >>>>> *page, unsigned long private, int * >>>>> break; >>>>> vma = vma->vm_next; >>>>> } >>>>> + >>>>> + if (PageHuge(page)) { >>>>> + if (vma) >>>>> + return alloc_huge_page_noerr(vma, address, 1); >>>>> + else >>>>> + return NULL; >>>>> + } >>>>> /* >>>>> - * queue_pages_range() confirms that @page belongs to some vma, >>>>> - * so vma shouldn't be NULL. >>>>> + * if !vma, alloc_page_vma() will use task or system default policy >>>>> */ >>>>> - BUG_ON(!vma); >>>>> - >>>>> - if (PageHuge(page)) >>>>> - return alloc_huge_page_noerr(vma, address, 1); >>>>> return alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, address); >>>>> } >>>>> #else >>>>> >>>> >>>> Hmm... So in essence it's mostly a revert of Naoya's patch, who seemed >>>> pretty certain that this >>>> situation shouldn't happen at all. What's the reasoning behind just >>> >>> I think this assumption may not correct. >>> Even if >>> address = __vma_address(page, vma); >>> and >>> vma->start < address < vma->end; >>> page_address_in_vma() may still return -EFAULT because of many other >>> conditions in it. >>> As a result the while loop in new_vma_page() may end with vma=NULL. >>> >>> Naoya, any idea? >> >> Yes, you totally make sense. So please apply Wanpeng's patch. > >Shouldn't it just be a revert of Naoya's patch? Otherwise we're >changing code paths unnecessarily. > Actually, the original target of Naoya's patch is try to fix potential dereference NULL pointer by Dan. http://marc.info/?l=linux-mm&m=137689530323257&w=2 This patch fix both the regression and potential dereference NULL pointer reported by Dan. http://marc.info/?l=linux-kernel&m=138726268626705&w=2 Regards, Wanpeng Li > >Thanks, >Sasha > >-- >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> ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <20131217065518.GA29118@hacker.(null)>]
* Re: mm: kernel BUG at mm/mempolicy.c:1203! [not found] ` <20131217065518.GA29118@hacker.(null)> @ 2013-12-17 6:57 ` Sasha Levin 0 siblings, 0 replies; 10+ messages in thread From: Sasha Levin @ 2013-12-17 6:57 UTC (permalink / raw) To: Wanpeng Li Cc: Naoya Horiguchi, Bob Liu, Andrew Morton, linux-mm@kvack.org, dan.carpenter On 12/17/2013 01:55 AM, Wanpeng Li wrote: > Hi Sasha, > On Tue, Dec 17, 2013 at 01:46:42AM -0500, Sasha Levin wrote: >> On 12/17/2013 01:11 AM, Naoya Horiguchi wrote: >>> Hello Bob, >>> >>> On Tue, Dec 17, 2013 at 12:38:49PM +0800, Bob Liu wrote: >>>> On 12/17/2013 09:10 AM, Sasha Levin wrote: >>>>> On 12/16/2013 07:44 PM, Bob Liu wrote: >>>>>> >>>>>> On 12/16/2013 07:37 AM, Sasha Levin wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> While fuzzing with trinity inside a KVM tools guest running latest -next >>>>>>> kernel, I've >>>>>>> stumbled on the following spew. >>>>>>> >>>>>>> This seems to be due to commit 0bf598d863e "mbind: add BUG_ON(!vma) in >>>>>>> new_vma_page()" >>>>>>> which added that BUG_ON. >>>>>> >>>>>> Could you take a try with this patch from Wanpeng Li? >>>>>> >>>>>> Thanks, >>>>>> -Bob >>>>>> >>>>>> Subject: [PATCH] mm/mempolicy: fix !vma in new_vma_page() >>>>>> .... >>>>>> Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com> >>>>>> index eca4a31..73b5a35 100644 >>>>>> --- a/mm/mempolicy.c >>>>>> +++ b/mm/mempolicy.c >>>>>> @@ -1197,14 +1197,16 @@ static struct page *new_vma_page(struct page >>>>>> *page, unsigned long private, int * >>>>>> break; >>>>>> vma = vma->vm_next; >>>>>> } >>>>>> + >>>>>> + if (PageHuge(page)) { >>>>>> + if (vma) >>>>>> + return alloc_huge_page_noerr(vma, address, 1); >>>>>> + else >>>>>> + return NULL; >>>>>> + } >>>>>> /* >>>>>> - * queue_pages_range() confirms that @page belongs to some vma, >>>>>> - * so vma shouldn't be NULL. >>>>>> + * if !vma, alloc_page_vma() will use task or system default policy >>>>>> */ >>>>>> - BUG_ON(!vma); >>>>>> - >>>>>> - if (PageHuge(page)) >>>>>> - return alloc_huge_page_noerr(vma, address, 1); >>>>>> return alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, address); >>>>>> } >>>>>> #else >>>>>> >>>>> >>>>> Hmm... So in essence it's mostly a revert of Naoya's patch, who seemed >>>>> pretty certain that this >>>>> situation shouldn't happen at all. What's the reasoning behind just >>>> >>>> I think this assumption may not correct. >>>> Even if >>>> address = __vma_address(page, vma); >>>> and >>>> vma->start < address < vma->end; >>>> page_address_in_vma() may still return -EFAULT because of many other >>>> conditions in it. >>>> As a result the while loop in new_vma_page() may end with vma=NULL. >>>> >>>> Naoya, any idea? >>> >>> Yes, you totally make sense. So please apply Wanpeng's patch. >> >> Shouldn't it just be a revert of Naoya's patch? Otherwise we're >> changing code paths unnecessarily. >> > > Actually, the original target of Naoya's patch is try to fix potential dereference > NULL pointer by Dan. http://marc.info/?l=linux-mm&m=137689530323257&w=2 > > This patch fix both the regression and potential dereference NULL pointer reported > by Dan. http://marc.info/?l=linux-kernel&m=138726268626705&w=2 Makes sense, thanks! Thanks, Sasha -- 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> ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-12-17 6:57 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-15 23:37 mm: kernel BUG at mm/mempolicy.c:1203! Sasha Levin
2013-12-16 0:26 ` Andrew Morton
2013-12-17 0:44 ` Bob Liu
2013-12-17 1:10 ` Sasha Levin
2013-12-17 4:38 ` Bob Liu
2013-12-17 6:11 ` Naoya Horiguchi
2013-12-17 6:23 ` Wanpeng Li
2013-12-17 6:46 ` Sasha Levin
2013-12-17 6:55 ` Wanpeng Li
[not found] ` <20131217065518.GA29118@hacker.(null)>
2013-12-17 6:57 ` Sasha Levin
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).