linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Linux-next: crash in alloc_huge_page()
@ 2021-08-11  2:22 Qian Cai
  2021-08-11  3:06 ` Matthew Wilcox
  0 siblings, 1 reply; 5+ messages in thread
From: Qian Cai @ 2021-08-11  2:22 UTC (permalink / raw)
  To: Mike Rapoport, David Hildenbrand, Mike Kravetz
  Cc: Linux Memory Management List, Linux Kernel Mailing List

Running a syscall fuzzer on the latest linux-next shortly will always trigger a crash in
alloc_huge_page(). It pointed to this line,

list_add(&page->lru, &h->hugepage_activelist);

and the page->lru has an address fffffffffffffffc for some reasons. Does it sound like some error code
had not been handled properly and had been propagated here instead? I tried reverting a few recent
commits for mm/hugetlb.c and mm/memblock.c without luck so far.


[ 8107.262232][T62705] Unable to handle kernel paging request at virtual address fffffffffffffffc
[ 8107.271516][T62705] Mem abort info:
[ 8107.275008][T62705]   ESR = 0x96000046
[ 8107.278754][T62705]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 8107.284760][T62705]   SET = 0, FnV = 0
[ 8107.288509][T62705]   EA = 0, S1PTW = 0
[ 8107.292342][T62705]   FSC = 0x06: level 2 translation fault
[ 8107.297912][T62705] Data abort info:
[ 8107.301487][T62705]   ISV = 0, ISS = 0x00000046
[ 8107.306021][T62705]   CM = 0, WnR = 1
[ 8107.309687][T62705] swapper pgtable: 64k pages, 48-bit VAs, pgdp=0000009f6e080000
[ 8107.317168][T62705] [fffffffffffffffc] pgd=1000009ffef90803, p4d=1000009ffef90803, pud=1000009ffef90803, pmd=0000000000000000
[ 8107.328836][T62705] Internal error: Oops: 96000046 [#1] SMP
[ 8107.334409][T62705] Modules linked in: cpufreq_userspace xfs loop cppc_cpufreq processor efivarfs ip_tables x_tables ext4 mbcache jbd2 dm_mod igb i2c_algo_bit nvme i2c_core mlx5_core nvme_core firmware_class
[ 8107.352873][T62705] CPU: 14 PID: 62705 Comm: trinity-c3 Not tainted 5.14.0-rc5-next-20210810+ #88
[ 8107.361742][T62705] Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 1.6 06/28/2020
[ 8107.370258][T62705] pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 8107.377907][T62705] pc : alloc_huge_page+0x8f4/0xbe0
__list_add at /usr/src/linux-next/./include/linux/list.h:71
(inlined by) list_add at /usr/src/linux-next/./include/linux/list.h:86
(inlined by) alloc_huge_page at /usr/src/linux-next/mm/hugetlb.c:2821
[ 8107.382873][T62705] lr : alloc_huge_page+0x8ac/0xbe0
[ 8107.387830][T62705] sp : ffff800028a8f4a0
[ 8107.391830][T62705] x29: ffff800028a8f4a0 x28: 0000000000000000 x27: ffff80001bc22e00
[ 8107.399659][T62705] x26: ffff80001bc22d68 x25: fffffffffffffffc x24: ffff0093d2952c00
[ 8107.407487][T62705] x23: 0000ffff00000000 x22: fffffffffffffff4 x21: ffff008c06a478c8
[ 8107.415314][T62705] x20: 1ffff00005151ea8 x19: 0000000000000001 x18: 0000000000000004
[ 8107.423141][T62705] x17: 1ffff0000323bb8f x16: 0000000000000000 x15: ffff0093d2953628
[ 8107.430969][T62705] x14: 0000000000000004 x13: 0000000000039c7c x12: ffff700005151e87
[ 8107.438796][T62705] x11: 1ffff00005151e86 x10: ffff700005151e86 x9 : dfff800000000000
[ 8107.446623][T62705] x8 : 0000000000000003 x7 : 0000000000000001 x6 : ffff800028a8f430
[ 8107.454450][T62705] x5 : 0000000000000004 x4 : 1ffff000037845c9 x3 : 0000800000000000
[ 8107.462277][T62705] x2 : ffff80001bc22e40 x1 : ffff80001bc22e40 x0 : 0000000000000004
[ 8107.470104][T62705] Call trace:
[ 8107.473237][T62705]  alloc_huge_page+0x8f4/0xbe0
[ 8107.477848][T62705]  hugetlb_no_page+0x214/0xba0
hugetlb_no_page at /usr/src/linux-next/mm/hugetlb.c:4905
[ 8107.482459][T62705]  hugetlb_fault+0x928/0xc88
[ 8107.486896][T62705]  handle_mm_fault+0x360/0x418
[ 8107.491508][T62705]  do_page_fault+0x220/0x880
[ 8107.495947][T62705]  do_translation_fault+0x7c/0xb0
[ 8107.500818][T62705]  do_mem_abort+0x70/0x1c8
[ 8107.505081][T62705]  el1_abort+0x44/0x68
[ 8107.508998][T62705]  el1h_64_sync_handler+0xb4/0xd0
[ 8107.513868][T62705]  el1h_64_sync+0x74/0x78
[ 8107.518045][T62705]  futex_cleanup+0x5d0/0x820
[ 8107.522483][T62705]  futex_exit_release+0x28/0x80
[ 8107.527180][T62705]  exit_mm_release+0x24/0x40
[ 8107.531619][T62705]  exit_mm+0x98/0x598
[ 8107.535449][T62705]  do_exit+0x4a0/0x1430
[ 8107.539451][T62705]  __secure_computing+0x178/0x1c8
[ 8107.544323][T62705]  syscall_trace_enter+0x580/0x870
[ 8107.549283][T62705]  do_el0_svc+0x1ec/0x2a8
[ 8107.553460][T62705]  el0_svc+0x64/0x130
[ 8107.557290][T62705]  el0t_64_sync_handler+0xb0/0xb8
[ 8107.562161][T62705]  el0t_64_sync+0x180/0x184
[ 8107.566515][T62705] Code: 38e06860 35001300 91002320 d2d00003 (f90006c2) 
[ 8107.573296][T62705] ---[ end trace 452794220e0c3075 ]---
[ 8107.578601][T62705] Kernel panic - not syncing: Oops: Fatal exception
[ 8107.585033][T62705] SMP: stopping secondary CPUs
[ 8107.589652][T62705] Kernel Offset: disabled
[ 8107.593826][T62705] CPU features: 0x00000251,20000846
[ 8107.598869][T62705] Memory Limit: none
[ 8107.602611][T62705] ---[ end Kernel panic - not syncing: Oops: Fatal exception ]---

[  249.512894][ T1511] Unable to handle kernel paging request at virtual address fffffffffffffffc
[  249.521628][ T1511] Mem abort info:
[  249.525118][ T1511]   ESR = 0x96000046
[  249.528866][ T1511]   EC = 0x25: DABT (current EL), IL = 32 bits
[  249.534871][ T1511]   SET = 0, FnV = 0
[  249.538618][ T1511]   EA = 0, S1PTW = 0
[  249.542450][ T1511]   FSC = 0x06: level 2 translation fault
[  249.548020][ T1511] Data abort info:
[  249.551591][ T1511]   ISV = 0, ISS = 0x00000046
[  249.556118][ T1511]   CM = 0, WnR = 1
[  249.559777][ T1511] swapper pgtable: 64k pages, 48-bit VAs, pgdp=0000009f6e080000
[  249.567257][ T1511] [fffffffffffffffc] pgd=1000009ffef90803, p4d=1000009ffef90803, pud=1000009ffef90803, pmd=0000000000000000
[  249.578698][ T1511] Internal error: Oops: 96000046 [#1] SMP
[  249.584270][ T1511] Modules linked in: loop cppc_cpufreq processor efivarfs ip_tables x_tables ext4 mbcache jbd2 dm_mod igb i2c_algo_bit nvme mlx5_core i2c_core nvme_core firmware_class
[  249.600819][ T1511] CPU: 6 PID: 1511 Comm: trinity-main Not tainted 5.14.0-rc5-next-20210810+ #54
[  249.609683][ T1511] Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 1.6 06/28/2020
[  249.618199][ T1511] pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  249.625849][ T1511] pc : alloc_huge_page+0x8ec/0xbd8
[  249.630812][ T1511] lr : alloc_huge_page+0x8a4/0xbd8
[  249.635770][ T1511] sp : ffff800023c4f550
[  249.639770][ T1511] x29: ffff800023c4f550 x28: 0000000000000000 x27: ffff80001bc22dc0
[  249.647598][ T1511] x26: ffff80001bc22d28 x25: fffffffffffffffc x24: ffff00088ad17dc0
[  249.655425][ T1511] x23: 0000ffff20000000 x22: fffffffffffffff4 x21: ffff0008db38d9d0
[  249.663251][ T1511] x20: 1ffff00004789ebe x19: 0000000000000001 x18: 0000000000000003
[  249.671078][ T1511] x17: 0000000000000000 x16: 0000000000000000 x15: ffff00088ad187e8
[  249.678905][ T1511] x14: 0000000000000003 x13: 0000000000010579 x12: ffff700004789e9d
[  249.686732][ T1511] x11: 1ffff00004789e9c x10: ffff700004789e9c x9 : dfff800000000000
[  249.694559][ T1511] x8 : 0000000000000003 x7 : 0000000000000001 x6 : ffff800023c4f4e0
[  249.702385][ T1511] x5 : 0000000000000004 x4 : 1ffff000037845c1 x3 : 0000800000000000
[  249.710212][ T1511] x2 : ffff80001bc22e00 x1 : ffff80001bc22e00 x0 : 0000000000000004
[  249.718039][ T1511] Call trace:
[  249.721172][ T1511]  alloc_huge_page+0x8ec/0xbd8
[  249.725783][ T1511]  hugetlb_no_page+0x214/0xba0
[  249.730394][ T1511]  hugetlb_fault+0x928/0xc88
[  249.734831][ T1511]  follow_hugetlb_page+0x28c/0x970
[  249.739788][ T1511]  __get_user_pages+0x180/0x8c8
[  249.744486][ T1511]  populate_vma_page_range+0x16c/0x200
[  249.749791][ T1511]  __mm_populate+0x170/0x2e8
[  249.754227][ T1511]  vm_mmap_pgoff+0x128/0x1c8
[  249.758665][ T1511]  ksys_mmap_pgoff+0x1e0/0x380
[  249.763276][ T1511]  __arm64_sys_mmap+0xd4/0x150
[  249.767888][ T1511]  invoke_syscall.constprop.0+0xdc/0x1d8
[  249.773368][ T1511]  do_el0_svc+0xe4/0x2a8
[  249.777457][ T1511]  el0_svc+0x64/0x130
[  249.781289][ T1511]  el0t_64_sync_handler+0xb0/0xb8
[  249.786159][ T1511]  el0t_64_sync+0x180/0x184
[  249.790512][ T1511] Code: 38e06860 350012e0 91002320 d2d00003 (f90006c2) 
[  249.797293][ T1511] ---[ end trace 66b18ed31e8dd1b2 ]---
[  249.802598][ T1511] Kernel panic - not syncing: Oops: Fatal exception
[  249.809030][ T1511] SMP: stopping secondary CPUs
[  249.813650][ T1511] Kernel Offset: disabled
[  249.817824][ T1511] CPU features: 0x00000251,20000846
[  249.822868][ T1511] Memory Limit: none
[  249.826609][ T1511] ---[ end Kernel panic - not syncing: Oops: Fatal exception ]---

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Linux-next: crash in alloc_huge_page()
  2021-08-11  2:22 Linux-next: crash in alloc_huge_page() Qian Cai
@ 2021-08-11  3:06 ` Matthew Wilcox
  2021-08-11 14:11   ` Mike Rapoport
  0 siblings, 1 reply; 5+ messages in thread
From: Matthew Wilcox @ 2021-08-11  3:06 UTC (permalink / raw)
  To: Qian Cai
  Cc: Mike Rapoport, David Hildenbrand, Mike Kravetz,
	Linux Memory Management List, Linux Kernel Mailing List

On Tue, Aug 10, 2021 at 10:22:37PM -0400, Qian Cai wrote:
> and the page->lru has an address fffffffffffffffc for some reasons. Does it sound like some error code
> had not been handled properly and had been propagated here instead? I tried reverting a few recent
> commits for mm/hugetlb.c and mm/memblock.c without luck so far.

Yes, ff..fc is going to be at offset 8 from the actual address, so
that's -12 and -12 is ...

#define ENOMEM          12      /* Out of memory */

so something's returning ERR_PTR(-ENOMEM) instead of NULL.

> [ 8107.262232][T62705] Unable to handle kernel paging request at virtual address fffffffffffffffc

These logs would be a lot easier to read if you snipped the irrelevant
timestamp and whatever this Txxxxx thing is.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Linux-next: crash in alloc_huge_page()
  2021-08-11  3:06 ` Matthew Wilcox
@ 2021-08-11 14:11   ` Mike Rapoport
  2021-08-11 14:25     ` Qian Cai
  0 siblings, 1 reply; 5+ messages in thread
From: Mike Rapoport @ 2021-08-11 14:11 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Qian Cai, David Hildenbrand, Mike Kravetz,
	Linux Memory Management List, Linux Kernel Mailing List

On Wed, Aug 11, 2021 at 04:06:18AM +0100, Matthew Wilcox wrote:
> On Tue, Aug 10, 2021 at 10:22:37PM -0400, Qian Cai wrote:
> > and the page->lru has an address fffffffffffffffc for some reasons. Does it sound like some error code
> > had not been handled properly and had been propagated here instead? I tried reverting a few recent
> > commits for mm/hugetlb.c and mm/memblock.c without luck so far.
> 
> Yes, ff..fc is going to be at offset 8 from the actual address, so
> that's -12 and -12 is ...
> 
> #define ENOMEM          12      /* Out of memory */
> 
> so something's returning ERR_PTR(-ENOMEM) instead of NULL.

page is not initialized in alloc_buddy_huge_page_with_mpol() and after
commit 2cfa8b23744f ("mm-hugetlb-add-support-for-mempolicy-mpol_preferred_many-fix") we have 

	struct page *page;

	...

	if (mpol_is_preferred_many(mpol)) {
		gfp_t gfp = gfp_mask | __GFP_NOWARN;

		gfp &=  ~(__GFP_DIRECT_RECLAIM | __GFP_NOFAIL);
		page = alloc_surplus_huge_page(h, gfp, nid, nodemask, false);

		/* Fallback to all nodes if page==NULL */
		nodemask = NULL;
	}

	if (!page)
		page = alloc_surplus_huge_page(h, gfp_mask, nid, nodemask, false

	mpol_cond_put(mpol);
	return page;

so for !mpol_is_preferred_many() we return an uninitialized variable.

This should fix it:

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 008662083fec..6337697f7ee4 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2152,7 +2152,7 @@ static
 struct page *alloc_buddy_huge_page_with_mpol(struct hstate *h,
 		struct vm_area_struct *vma, unsigned long addr)
 {
-	struct page *page;
+	struct page *page = NULL;
 	struct mempolicy *mpol;
 	gfp_t gfp_mask = htlb_alloc_mask(h);
 	int nid;
 
-- 
Sincerely yours,
Mike.

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: Linux-next: crash in alloc_huge_page()
  2021-08-11 14:11   ` Mike Rapoport
@ 2021-08-11 14:25     ` Qian Cai
  2021-08-11 15:59       ` Mike Kravetz
  0 siblings, 1 reply; 5+ messages in thread
From: Qian Cai @ 2021-08-11 14:25 UTC (permalink / raw)
  To: Mike Rapoport, Matthew Wilcox, Andrew Morton
  Cc: David Hildenbrand, Mike Kravetz, Linux Memory Management List,
	Linux Kernel Mailing List



On 8/11/2021 10:11 AM, Mike Rapoport wrote:
> On Wed, Aug 11, 2021 at 04:06:18AM +0100, Matthew Wilcox wrote:
>> On Tue, Aug 10, 2021 at 10:22:37PM -0400, Qian Cai wrote:
>>> and the page->lru has an address fffffffffffffffc for some reasons. Does it sound like some error code
>>> had not been handled properly and had been propagated here instead? I tried reverting a few recent
>>> commits for mm/hugetlb.c and mm/memblock.c without luck so far.
>>
>> Yes, ff..fc is going to be at offset 8 from the actual address, so
>> that's -12 and -12 is ...
>>
>> #define ENOMEM          12      /* Out of memory */
>>
>> so something's returning ERR_PTR(-ENOMEM) instead of NULL.
> 
> page is not initialized in alloc_buddy_huge_page_with_mpol() and after
> commit 2cfa8b23744f ("mm-hugetlb-add-support-for-mempolicy-mpol_preferred_many-fix") we have 

Good catch, Mike! Pretty sure I missed to test that commit thought that was an old commit along
with the rest of the mpol_preferred series.

It is a dream that one day mm tree could like other subsystem trees where "git tag --contains"
would work to indicate which linux-next tags contains a particular commit to tell the timeline
of it. Right now, we have those commits ID always changed and commit date is meaningless for
mm commits in linux-next.

> 
> 	struct page *page;
> 
> 	...
> 
> 	if (mpol_is_preferred_many(mpol)) {
> 		gfp_t gfp = gfp_mask | __GFP_NOWARN;
> 
> 		gfp &=  ~(__GFP_DIRECT_RECLAIM | __GFP_NOFAIL);
> 		page = alloc_surplus_huge_page(h, gfp, nid, nodemask, false);
> 
> 		/* Fallback to all nodes if page==NULL */
> 		nodemask = NULL;
> 	}
> 
> 	if (!page)
> 		page = alloc_surplus_huge_page(h, gfp_mask, nid, nodemask, false
> 
> 	mpol_cond_put(mpol);
> 	return page;
> 
> so for !mpol_is_preferred_many() we return an uninitialized variable.
> 
> This should fix it:
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 008662083fec..6337697f7ee4 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2152,7 +2152,7 @@ static
>  struct page *alloc_buddy_huge_page_with_mpol(struct hstate *h,
>  		struct vm_area_struct *vma, unsigned long addr)
>  {
> -	struct page *page;
> +	struct page *page = NULL;
>  	struct mempolicy *mpol;
>  	gfp_t gfp_mask = htlb_alloc_mask(h);
>  	int nid;
>  
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Linux-next: crash in alloc_huge_page()
  2021-08-11 14:25     ` Qian Cai
@ 2021-08-11 15:59       ` Mike Kravetz
  0 siblings, 0 replies; 5+ messages in thread
From: Mike Kravetz @ 2021-08-11 15:59 UTC (permalink / raw)
  To: Qian Cai, Mike Rapoport, Matthew Wilcox, Andrew Morton
  Cc: David Hildenbrand, Linux Memory Management List,
	Linux Kernel Mailing List

On 8/11/21 7:25 AM, Qian Cai wrote:
> On 8/11/2021 10:11 AM, Mike Rapoport wrote:
>> On Wed, Aug 11, 2021 at 04:06:18AM +0100, Matthew Wilcox wrote:
>>> On Tue, Aug 10, 2021 at 10:22:37PM -0400, Qian Cai wrote:
>>>> and the page->lru has an address fffffffffffffffc for some reasons. Does it sound like some error code
>>>> had not been handled properly and had been propagated here instead? I tried reverting a few recent
>>>> commits for mm/hugetlb.c and mm/memblock.c without luck so far.
>>>
>>> Yes, ff..fc is going to be at offset 8 from the actual address, so
>>> that's -12 and -12 is ...
>>>
>>> #define ENOMEM          12      /* Out of memory */
>>>
>>> so something's returning ERR_PTR(-ENOMEM) instead of NULL.
>>
>> page is not initialized in alloc_buddy_huge_page_with_mpol() and after
>> commit 2cfa8b23744f ("mm-hugetlb-add-support-for-mempolicy-mpol_preferred_many-fix") we have 
> 
> Good catch, Mike! Pretty sure I missed to test that commit thought that was an old commit along
> with the rest of the mpol_preferred series.
> 
> It is a dream that one day mm tree could like other subsystem trees where "git tag --contains"
> would work to indicate which linux-next tags contains a particular commit to tell the timeline
> of it. Right now, we have those commits ID always changed and commit date is meaningless for
> mm commits in linux-next.
> 
>> This should fix it:
>>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 008662083fec..6337697f7ee4 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -2152,7 +2152,7 @@ static
>>  struct page *alloc_buddy_huge_page_with_mpol(struct hstate *h,
>>  		struct vm_area_struct *vma, unsigned long addr)
>>  {
>> -	struct page *page;
>> +	struct page *page = NULL;
>>  	struct mempolicy *mpol;
>>  	gfp_t gfp_mask = htlb_alloc_mask(h);
>>  	int nid;
>>  
>>

Thanks everyone!

Looks like clang already found this.  Andrew added this to his tree
yesterday:

https://lkml.kernel.org/r/20210810200632.3812797-1-nathan@kernel.org

-- 
Mike Kravetz

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-08-11 15:59 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-11  2:22 Linux-next: crash in alloc_huge_page() Qian Cai
2021-08-11  3:06 ` Matthew Wilcox
2021-08-11 14:11   ` Mike Rapoport
2021-08-11 14:25     ` Qian Cai
2021-08-11 15:59       ` Mike Kravetz

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).