Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1370583 > unrolled thread
| Started by | Vlastimil Babka <vbabka@suse.cz> |
|---|---|
| First post | 2016-04-04 14:10 +0200 |
| Last post | 2016-04-04 14:10 +0200 |
| Articles | 1 — 1 participant |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: mm: BUG in khugepaged_scan_mm_slot Vlastimil Babka <vbabka@suse.cz> - 2016-04-04 14:10 +0200
| From | Vlastimil Babka <vbabka@suse.cz> |
|---|---|
| Date | 2016-04-04 14:10 +0200 |
| Subject | Re: mm: BUG in khugepaged_scan_mm_slot |
| Message-ID | <rkbur-2OO-27@gated-at.bofh.it> |
[+CC Andrea] On 04/02/2016 11:48 AM, Dmitry Vyukov wrote: > Hello, > > The following program triggers a BUG in khugepaged_scan_mm_slot: > > > vma ffff880032698f90 start 0000000020c57000 end 0000000020c58000 > next ffff88003269a1b8 prev ffff88003269ac18 mm ffff88005e274780 > prot 35 anon_vma ffff88003182c000 vm_ops (null) > pgoff fed00 file ffff8800324552c0 private_data (null) > flags: 0x5144477(read|write|exec|mayread|maywrite|mayexec|pfnmap|io|dontexpand|account) > ------------[ cut here ]------------ > kernel BUG at mm/huge_memory.c:2313! > invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN That's VM_BUG_ON_VMA(vma->vm_flags & VM_NO_THP, vma) in hugepage_vma_check(). #define VM_NO_THP (VM_SPECIAL | VM_HUGETLB | VM_SHARED | VM_MAYSHARE) #define VM_SPECIAL (VM_IO | VM_DONTEXPAND | VM_PFNMAP | VM_MIXEDMAP) Of those, we have VM_IO | VM_DONTEXPAND. I don't know if it's valid for a vma with anon_vma to have such flags, if yes, we should probably modify hugepage_vma_check(). Called from khugepaged_scan_mm_slot() it should just return false out VM_NO_THP. Called from collapse_huge_page() it could keep the VM_BUG_ON. Or maybe just have VM_BUG_ON(!hugepage_vma_check()) there? Hmm actually no, there's a mmap_sem release for read and then acquire for write, so we can't rely on the check done earlier from khugepaged_scan_mm_slot(). So we should probably just change the VM_BUG_ON to another "return false" condition. Unless the VM_BUG_ON uncovered a real bug and the earlier conditions in hugepage_vma_check() should guarantee the VM_BUG_ON be false for any vma.
Back to top | Article view | linux.kernel
csiph-web