* mm: BUG in unmap_page_range @ 2014-08-02 21:58 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-08-02 21:58 UTC (permalink / raw) To: linux-mm Cc: Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Mel Gorman, Johannes Weiner, Cyrill Gorcunov Hi all, While fuzzing with trinity inside a KVM tools guest running the latest -next kernel, I've stumbled on the following spew: [ 2957.087977] BUG: unable to handle kernel paging request at ffffea0003480008 [ 2957.088008] IP: unmap_page_range (mm/memory.c:1132 mm/memory.c:1256 mm/memory.c:1277 mm/memory.c:1301) [ 2957.088024] PGD 7fffc6067 PUD 7fffc5067 PMD 0 [ 2957.088041] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 2957.088087] Dumping ftrace buffer: [ 2957.088266] (ftrace buffer empty) [ 2957.088279] Modules linked in: [ 2957.088293] CPU: 2 PID: 15417 Comm: trinity-c200 Not tainted 3.16.0-rc7-next-20140801-sasha-00047-gd6ce559 #990 [ 2957.088301] task: ffff8807a8c50000 ti: ffff880739fb4000 task.ti: ffff880739fb4000 [ 2957.088320] RIP: unmap_page_range (mm/memory.c:1132 mm/memory.c:1256 mm/memory.c:1277 mm/memory.c:1301) [ 2957.088328] RSP: 0018:ffff880739fb7c58 EFLAGS: 00010246 [ 2957.088336] RAX: 0000000000000000 RBX: ffff880eb2bdbed8 RCX: dfff971b42800000 [ 2957.088343] RDX: 1ffff100e73f6fc4 RSI: 00007f00e85db000 RDI: ffffea0003480008 [ 2957.088350] RBP: ffff880739fb7d58 R08: 0000000000000001 R09: 0000000000b6e000 [ 2957.088357] R10: 0000000000000000 R11: 0000000000000001 R12: ffffea0003480000 [ 2957.088365] R13: 00000000d2000700 R14: 00007f00e85dc000 R15: 00007f00e85db000 [ 2957.088374] FS: 00007f00e85d8700(0000) GS:ffff88177fa00000(0000) knlGS:0000000000000000 [ 2957.088381] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2957.088387] CR2: ffffea0003480008 CR3: 00000007a802a000 CR4: 00000000000006a0 [ 2957.088406] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2957.088413] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 [ 2957.088416] Stack: [ 2957.088432] ffff88171726d570 0000000000000010 0000000000000008 00000000d2000730 [ 2957.088450] 0000000019d00250 00007f00e85dc000 ffff880f9d311900 ffff880739fb7e20 [ 2957.088466] ffff8807a8c507a0 ffff8807a8c50000 ffff8807a75fe000 ffff8807ceaa7a10 [ 2957.088469] Call Trace: [ 2957.088490] unmap_single_vma (mm/memory.c:1348) [ 2957.088505] unmap_vmas (mm/memory.c:1375 (discriminator 3)) [ 2957.088520] unmap_region (mm/mmap.c:2386 (discriminator 4)) [ 2957.088542] ? vma_rb_erase (mm/mmap.c:454 include/linux/rbtree_augmented.h:219 include/linux/rbtree_augmented.h:227 mm/mmap.c:493) [ 2957.088559] ? vmacache_update (mm/vmacache.c:61) [ 2957.088572] do_munmap (mm/mmap.c:2581) [ 2957.088583] vm_munmap (mm/mmap.c:2596) [ 2957.088595] SyS_munmap (mm/mmap.c:2601) [ 2957.088616] tracesys (arch/x86/kernel/entry_64.S:541) [ 2957.088770] Code: ff ff e8 f9 5f 07 00 48 8b 45 90 80 48 18 01 4d 85 e4 0f 84 8b fe ff ff 45 84 ed 0f 85 fc 03 00 00 49 8d 7c 24 08 e8 b5 67 07 00 <41> f6 44 24 08 01 0f 84 29 02 00 00 83 6d c8 01 4c 89 e7 e8 bd All code ======== 0: ff (bad) 1: ff e8 ljmpq *<internal disassembler error> 3: f9 stc 4: 5f pop %rdi 5: 07 (bad) 6: 00 48 8b add %cl,-0x75(%rax) 9: 45 90 rex.RB xchg %eax,%r8d b: 80 48 18 01 orb $0x1,0x18(%rax) f: 4d 85 e4 test %r12,%r12 12: 0f 84 8b fe ff ff je 0xfffffffffffffea3 18: 45 84 ed test %r13b,%r13b 1b: 0f 85 fc 03 00 00 jne 0x41d 21: 49 8d 7c 24 08 lea 0x8(%r12),%rdi 26: e8 b5 67 07 00 callq 0x767e0 2b:* 41 f6 44 24 08 01 testb $0x1,0x8(%r12) <-- trapping instruction 31: 0f 84 29 02 00 00 je 0x260 37: 83 6d c8 01 subl $0x1,-0x38(%rbp) 3b: 4c 89 e7 mov %r12,%rdi 3e: e8 .byte 0xe8 3f: bd .byte 0xbd ... Code starting with the faulting instruction =========================================== 0: 41 f6 44 24 08 01 testb $0x1,0x8(%r12) 6: 0f 84 29 02 00 00 je 0x235 c: 83 6d c8 01 subl $0x1,-0x38(%rbp) 10: 4c 89 e7 mov %r12,%rdi 13: e8 .byte 0xe8 14: bd .byte 0xbd ... [ 2957.088784] RIP unmap_page_range (mm/memory.c:1132 mm/memory.c:1256 mm/memory.c:1277 mm/memory.c:1301) [ 2957.088789] RSP <ffff880739fb7c58> [ 2957.088794] CR2: ffffea0003480008 Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* mm: BUG in unmap_page_range @ 2014-08-02 21:58 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-08-02 21:58 UTC (permalink / raw) To: linux-mm Cc: Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Mel Gorman, Johannes Weiner, Cyrill Gorcunov Hi all, While fuzzing with trinity inside a KVM tools guest running the latest -next kernel, I've stumbled on the following spew: [ 2957.087977] BUG: unable to handle kernel paging request at ffffea0003480008 [ 2957.088008] IP: unmap_page_range (mm/memory.c:1132 mm/memory.c:1256 mm/memory.c:1277 mm/memory.c:1301) [ 2957.088024] PGD 7fffc6067 PUD 7fffc5067 PMD 0 [ 2957.088041] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 2957.088087] Dumping ftrace buffer: [ 2957.088266] (ftrace buffer empty) [ 2957.088279] Modules linked in: [ 2957.088293] CPU: 2 PID: 15417 Comm: trinity-c200 Not tainted 3.16.0-rc7-next-20140801-sasha-00047-gd6ce559 #990 [ 2957.088301] task: ffff8807a8c50000 ti: ffff880739fb4000 task.ti: ffff880739fb4000 [ 2957.088320] RIP: unmap_page_range (mm/memory.c:1132 mm/memory.c:1256 mm/memory.c:1277 mm/memory.c:1301) [ 2957.088328] RSP: 0018:ffff880739fb7c58 EFLAGS: 00010246 [ 2957.088336] RAX: 0000000000000000 RBX: ffff880eb2bdbed8 RCX: dfff971b42800000 [ 2957.088343] RDX: 1ffff100e73f6fc4 RSI: 00007f00e85db000 RDI: ffffea0003480008 [ 2957.088350] RBP: ffff880739fb7d58 R08: 0000000000000001 R09: 0000000000b6e000 [ 2957.088357] R10: 0000000000000000 R11: 0000000000000001 R12: ffffea0003480000 [ 2957.088365] R13: 00000000d2000700 R14: 00007f00e85dc000 R15: 00007f00e85db000 [ 2957.088374] FS: 00007f00e85d8700(0000) GS:ffff88177fa00000(0000) knlGS:0000000000000000 [ 2957.088381] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2957.088387] CR2: ffffea0003480008 CR3: 00000007a802a000 CR4: 00000000000006a0 [ 2957.088406] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2957.088413] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 [ 2957.088416] Stack: [ 2957.088432] ffff88171726d570 0000000000000010 0000000000000008 00000000d2000730 [ 2957.088450] 0000000019d00250 00007f00e85dc000 ffff880f9d311900 ffff880739fb7e20 [ 2957.088466] ffff8807a8c507a0 ffff8807a8c50000 ffff8807a75fe000 ffff8807ceaa7a10 [ 2957.088469] Call Trace: [ 2957.088490] unmap_single_vma (mm/memory.c:1348) [ 2957.088505] unmap_vmas (mm/memory.c:1375 (discriminator 3)) [ 2957.088520] unmap_region (mm/mmap.c:2386 (discriminator 4)) [ 2957.088542] ? vma_rb_erase (mm/mmap.c:454 include/linux/rbtree_augmented.h:219 include/linux/rbtree_augmented.h:227 mm/mmap.c:493) [ 2957.088559] ? vmacache_update (mm/vmacache.c:61) [ 2957.088572] do_munmap (mm/mmap.c:2581) [ 2957.088583] vm_munmap (mm/mmap.c:2596) [ 2957.088595] SyS_munmap (mm/mmap.c:2601) [ 2957.088616] tracesys (arch/x86/kernel/entry_64.S:541) [ 2957.088770] Code: ff ff e8 f9 5f 07 00 48 8b 45 90 80 48 18 01 4d 85 e4 0f 84 8b fe ff ff 45 84 ed 0f 85 fc 03 00 00 49 8d 7c 24 08 e8 b5 67 07 00 <41> f6 44 24 08 01 0f 84 29 02 00 00 83 6d c8 01 4c 89 e7 e8 bd All code ======== 0: ff (bad) 1: ff e8 ljmpq *<internal disassembler error> 3: f9 stc 4: 5f pop %rdi 5: 07 (bad) 6: 00 48 8b add %cl,-0x75(%rax) 9: 45 90 rex.RB xchg %eax,%r8d b: 80 48 18 01 orb $0x1,0x18(%rax) f: 4d 85 e4 test %r12,%r12 12: 0f 84 8b fe ff ff je 0xfffffffffffffea3 18: 45 84 ed test %r13b,%r13b 1b: 0f 85 fc 03 00 00 jne 0x41d 21: 49 8d 7c 24 08 lea 0x8(%r12),%rdi 26: e8 b5 67 07 00 callq 0x767e0 2b:* 41 f6 44 24 08 01 testb $0x1,0x8(%r12) <-- trapping instruction 31: 0f 84 29 02 00 00 je 0x260 37: 83 6d c8 01 subl $0x1,-0x38(%rbp) 3b: 4c 89 e7 mov %r12,%rdi 3e: e8 .byte 0xe8 3f: bd .byte 0xbd ... Code starting with the faulting instruction =========================================== 0: 41 f6 44 24 08 01 testb $0x1,0x8(%r12) 6: 0f 84 29 02 00 00 je 0x235 c: 83 6d c8 01 subl $0x1,-0x38(%rbp) 10: 4c 89 e7 mov %r12,%rdi 13: e8 .byte 0xe8 14: bd .byte 0xbd ... [ 2957.088784] RIP unmap_page_range (mm/memory.c:1132 mm/memory.c:1256 mm/memory.c:1277 mm/memory.c:1301) [ 2957.088789] RSP <ffff880739fb7c58> [ 2957.088794] CR2: ffffea0003480008 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-08-02 21:58 ` Sasha Levin @ 2014-08-04 11:40 ` Hugh Dickins -1 siblings, 0 replies; 86+ messages in thread From: Hugh Dickins @ 2014-08-04 11:40 UTC (permalink / raw) To: Mel Gorman Cc: Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Sat, 2 Aug 2014, Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest running the latest -next > kernel, I've stumbled on the following spew: > > [ 2957.087977] BUG: unable to handle kernel paging request at ffffea0003480008 > [ 2957.088008] IP: unmap_page_range (mm/memory.c:1132 mm/memory.c:1256 mm/memory.c:1277 mm/memory.c:1301) > [ 2957.088024] PGD 7fffc6067 PUD 7fffc5067 PMD 0 > [ 2957.088041] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 2957.088087] Dumping ftrace buffer: > [ 2957.088266] (ftrace buffer empty) > [ 2957.088279] Modules linked in: > [ 2957.088293] CPU: 2 PID: 15417 Comm: trinity-c200 Not tainted 3.16.0-rc7-next-20140801-sasha-00047-gd6ce559 #990 > [ 2957.088301] task: ffff8807a8c50000 ti: ffff880739fb4000 task.ti: ffff880739fb4000 > [ 2957.088320] RIP: unmap_page_range (mm/memory.c:1132 mm/memory.c:1256 mm/memory.c:1277 mm/memory.c:1301) > [ 2957.088328] RSP: 0018:ffff880739fb7c58 EFLAGS: 00010246 > [ 2957.088336] RAX: 0000000000000000 RBX: ffff880eb2bdbed8 RCX: dfff971b42800000 > [ 2957.088343] RDX: 1ffff100e73f6fc4 RSI: 00007f00e85db000 RDI: ffffea0003480008 > [ 2957.088350] RBP: ffff880739fb7d58 R08: 0000000000000001 R09: 0000000000b6e000 > [ 2957.088357] R10: 0000000000000000 R11: 0000000000000001 R12: ffffea0003480000 > [ 2957.088365] R13: 00000000d2000700 R14: 00007f00e85dc000 R15: 00007f00e85db000 > [ 2957.088374] FS: 00007f00e85d8700(0000) GS:ffff88177fa00000(0000) knlGS:0000000000000000 > [ 2957.088381] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 2957.088387] CR2: ffffea0003480008 CR3: 00000007a802a000 CR4: 00000000000006a0 > [ 2957.088406] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 2957.088413] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 > [ 2957.088416] Stack: > [ 2957.088432] ffff88171726d570 0000000000000010 0000000000000008 00000000d2000730 > [ 2957.088450] 0000000019d00250 00007f00e85dc000 ffff880f9d311900 ffff880739fb7e20 > [ 2957.088466] ffff8807a8c507a0 ffff8807a8c50000 ffff8807a75fe000 ffff8807ceaa7a10 > [ 2957.088469] Call Trace: > [ 2957.088490] unmap_single_vma (mm/memory.c:1348) > [ 2957.088505] unmap_vmas (mm/memory.c:1375 (discriminator 3)) > [ 2957.088520] unmap_region (mm/mmap.c:2386 (discriminator 4)) > [ 2957.088542] ? vma_rb_erase (mm/mmap.c:454 include/linux/rbtree_augmented.h:219 include/linux/rbtree_augmented.h:227 mm/mmap.c:493) > [ 2957.088559] ? vmacache_update (mm/vmacache.c:61) > [ 2957.088572] do_munmap (mm/mmap.c:2581) > [ 2957.088583] vm_munmap (mm/mmap.c:2596) > [ 2957.088595] SyS_munmap (mm/mmap.c:2601) > [ 2957.088616] tracesys (arch/x86/kernel/entry_64.S:541) > [ 2957.088770] Code: ff ff e8 f9 5f 07 00 48 8b 45 90 80 48 18 01 4d 85 e4 0f 84 8b fe ff ff 45 84 ed 0f 85 fc 03 00 00 49 8d 7c 24 08 e8 b5 67 07 00 <41> f6 44 24 08 01 0f 84 29 02 00 00 83 6d c8 01 4c 89 e7 e8 bd > All code > ======== > 0: ff (bad) > 1: ff e8 ljmpq *<internal disassembler error> > 3: f9 stc > 4: 5f pop %rdi > 5: 07 (bad) > 6: 00 48 8b add %cl,-0x75(%rax) > 9: 45 90 rex.RB xchg %eax,%r8d > b: 80 48 18 01 orb $0x1,0x18(%rax) > f: 4d 85 e4 test %r12,%r12 > 12: 0f 84 8b fe ff ff je 0xfffffffffffffea3 > 18: 45 84 ed test %r13b,%r13b > 1b: 0f 85 fc 03 00 00 jne 0x41d > 21: 49 8d 7c 24 08 lea 0x8(%r12),%rdi > 26: e8 b5 67 07 00 callq 0x767e0 > 2b:* 41 f6 44 24 08 01 testb $0x1,0x8(%r12) <-- trapping instruction > 31: 0f 84 29 02 00 00 je 0x260 > 37: 83 6d c8 01 subl $0x1,-0x38(%rbp) > 3b: 4c 89 e7 mov %r12,%rdi > 3e: e8 .byte 0xe8 > 3f: bd .byte 0xbd This differs in which functions got inlined (unmap_page_range showing up in place of zap_pte_range), but this is the same "if (PageAnon(page))" that Sasha reported in the "hang in shmem_fallocate" thread on June 26th. I can see what it is now, and here is most of a patch (which I don't expect to satisfy Trinity yet); at this point I think I had better hand it over to Mel, to complete or to discard. [INCOMPLETE PATCH] x86,mm: fix pte_special versus pte_numa Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 at mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels: where zap_pte_range() checks page->mapping to see if PageAnon(page). Those addresses fit struct pages for pfns d2001 and d2000, and in each dump a register or a stack slot showed d2001730 or d2000730: pte flags 0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has a hole between cfffffff and 100000000, which would need special access. Commit c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL pte no longer passes the pte_special() test, so zap_pte_range() goes on to try to access a non-existent struct page. Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). It's unclear why c46a7c817e66 added pte_numa() test to vm_normal_page(), and moved its is_zero_pfn() test from slow to fast path: I suspect both were papering over PROT_NONE issues seen with inadequate pte_special(). Revert vm_normal_page() to how it was before, relying on pte_special(). I find it confusing, that the only example of ARCH_USES_NUMA_PROT_NONE no longer uses PROTNONE for NUMA, but SPECIAL instead: update the asm-generic comment a little, but that config option remains unhelpful. But more seriously, I think this patch is incomplete: aren't there other places which need to be handling PROTNONE along with PRESENT? For example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, but on a PROT_NONE area, I think that will now make it pte_special()? So it ought to clear _PAGE_PROTNONE too. Or maybe we can never pte_mknuma() on a PROT_NONE area - there would be no point? Around here I began to wonder if it was just a mistake to have deserted the PROTNONE for NUMA model: I know Linus had a strong reaction against it, and I've never delved into its drawbacks myself; but bringing yet another (SPECIAL) flag into the game is not an obvious improvement. Should we just revert c46a7c817e66, or would that be a mistake? Let me hand this over to Mel now... Partially-Fixes: c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") Reported-by: Sasha Levin <sasha.levin@oracle.com> Not-yet-Signed-off-by: Hugh Dickins <hughd@google.com> Cc: stable@vger.kernel.org [3.16] --- arch/x86/include/asm/pgtable.h | 9 +++++++-- include/asm-generic/pgtable.h | 6 +++--- mm/memory.c | 7 +++---- 3 files changed, 13 insertions(+), 9 deletions(-) --- v3.16/arch/x86/include/asm/pgtable.h 2014-08-03 15:25:02.000000000 -0700 +++ linux/arch/x86/include/asm/pgtable.h 2014-08-03 17:36:02.364552987 -0700 @@ -131,8 +131,13 @@ static inline int pte_exec(pte_t pte) static inline int pte_special(pte_t pte) { - return (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_SPECIAL)) == - (_PAGE_PRESENT|_PAGE_SPECIAL); + /* + * See CONFIG_NUMA_BALANCING CONFIG_ARCH_USES_NUMA_PROT_NONE pte_numa() + * in include/asm-generic/pgtable.h: on x86 we have _PAGE_BIT_NUMA == + * _PAGE_BIT_GLOBAL+1 == __PAGE_BIT_SOFTW1 == _PAGE_BIT_SPECIAL. + */ + return (pte_flags(pte) & _PAGE_SPECIAL) && + (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_PROTNONE)); } static inline unsigned long pte_pfn(pte_t pte) --- v3.16/include/asm-generic/pgtable.h 2014-08-03 15:25:02.000000000 -0700 +++ linux/include/asm-generic/pgtable.h 2014-08-03 17:36:02.364552987 -0700 @@ -662,9 +662,9 @@ static inline int pmd_trans_unstable(pmd #ifdef CONFIG_NUMA_BALANCING #ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE /* - * _PAGE_NUMA works identical to _PAGE_PROTNONE (it's actually the - * same bit too). It's set only when _PAGE_PRESET is not set and it's - * never set if _PAGE_PRESENT is set. + * _PAGE_NUMA works identically to _PAGE_PROTNONE. + * It is set only when neither _PAGE_PRESENT nor _PAGE_PROTNONE is set. + * This allows it to share a bit set only when present e.g. _PAGE_SPECIAL. * * pte/pmd_present() returns true if pte/pmd_numa returns true. Page * fault triggers on those regions if pte/pmd_numa returns true --- v3.16/mm/memory.c 2014-08-03 15:25:02.000000000 -0700 +++ linux/mm/memory.c 2014-08-03 17:36:02.368552987 -0700 @@ -751,7 +751,7 @@ struct page *vm_normal_page(struct vm_ar unsigned long pfn = pte_pfn(pte); if (HAVE_PTE_SPECIAL) { - if (likely(!pte_special(pte) || pte_numa(pte))) + if (likely(!pte_special(pte))) goto check_pfn; if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)) return NULL; @@ -777,15 +777,14 @@ struct page *vm_normal_page(struct vm_ar } } + if (is_zero_pfn(pfn)) + return NULL; check_pfn: if (unlikely(pfn > highest_memmap_pfn)) { print_bad_pte(vma, addr, pte, NULL); return NULL; } - if (is_zero_pfn(pfn)) - return NULL; - /* * NOTE! We still have PageReserved() pages in the page tables. * eg. VDSO mappings can cause them to exist. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-04 11:40 ` Hugh Dickins 0 siblings, 0 replies; 86+ messages in thread From: Hugh Dickins @ 2014-08-04 11:40 UTC (permalink / raw) To: Mel Gorman Cc: Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Sat, 2 Aug 2014, Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest running the latest -next > kernel, I've stumbled on the following spew: > > [ 2957.087977] BUG: unable to handle kernel paging request at ffffea0003480008 > [ 2957.088008] IP: unmap_page_range (mm/memory.c:1132 mm/memory.c:1256 mm/memory.c:1277 mm/memory.c:1301) > [ 2957.088024] PGD 7fffc6067 PUD 7fffc5067 PMD 0 > [ 2957.088041] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 2957.088087] Dumping ftrace buffer: > [ 2957.088266] (ftrace buffer empty) > [ 2957.088279] Modules linked in: > [ 2957.088293] CPU: 2 PID: 15417 Comm: trinity-c200 Not tainted 3.16.0-rc7-next-20140801-sasha-00047-gd6ce559 #990 > [ 2957.088301] task: ffff8807a8c50000 ti: ffff880739fb4000 task.ti: ffff880739fb4000 > [ 2957.088320] RIP: unmap_page_range (mm/memory.c:1132 mm/memory.c:1256 mm/memory.c:1277 mm/memory.c:1301) > [ 2957.088328] RSP: 0018:ffff880739fb7c58 EFLAGS: 00010246 > [ 2957.088336] RAX: 0000000000000000 RBX: ffff880eb2bdbed8 RCX: dfff971b42800000 > [ 2957.088343] RDX: 1ffff100e73f6fc4 RSI: 00007f00e85db000 RDI: ffffea0003480008 > [ 2957.088350] RBP: ffff880739fb7d58 R08: 0000000000000001 R09: 0000000000b6e000 > [ 2957.088357] R10: 0000000000000000 R11: 0000000000000001 R12: ffffea0003480000 > [ 2957.088365] R13: 00000000d2000700 R14: 00007f00e85dc000 R15: 00007f00e85db000 > [ 2957.088374] FS: 00007f00e85d8700(0000) GS:ffff88177fa00000(0000) knlGS:0000000000000000 > [ 2957.088381] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 2957.088387] CR2: ffffea0003480008 CR3: 00000007a802a000 CR4: 00000000000006a0 > [ 2957.088406] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 2957.088413] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 > [ 2957.088416] Stack: > [ 2957.088432] ffff88171726d570 0000000000000010 0000000000000008 00000000d2000730 > [ 2957.088450] 0000000019d00250 00007f00e85dc000 ffff880f9d311900 ffff880739fb7e20 > [ 2957.088466] ffff8807a8c507a0 ffff8807a8c50000 ffff8807a75fe000 ffff8807ceaa7a10 > [ 2957.088469] Call Trace: > [ 2957.088490] unmap_single_vma (mm/memory.c:1348) > [ 2957.088505] unmap_vmas (mm/memory.c:1375 (discriminator 3)) > [ 2957.088520] unmap_region (mm/mmap.c:2386 (discriminator 4)) > [ 2957.088542] ? vma_rb_erase (mm/mmap.c:454 include/linux/rbtree_augmented.h:219 include/linux/rbtree_augmented.h:227 mm/mmap.c:493) > [ 2957.088559] ? vmacache_update (mm/vmacache.c:61) > [ 2957.088572] do_munmap (mm/mmap.c:2581) > [ 2957.088583] vm_munmap (mm/mmap.c:2596) > [ 2957.088595] SyS_munmap (mm/mmap.c:2601) > [ 2957.088616] tracesys (arch/x86/kernel/entry_64.S:541) > [ 2957.088770] Code: ff ff e8 f9 5f 07 00 48 8b 45 90 80 48 18 01 4d 85 e4 0f 84 8b fe ff ff 45 84 ed 0f 85 fc 03 00 00 49 8d 7c 24 08 e8 b5 67 07 00 <41> f6 44 24 08 01 0f 84 29 02 00 00 83 6d c8 01 4c 89 e7 e8 bd > All code > ======== > 0: ff (bad) > 1: ff e8 ljmpq *<internal disassembler error> > 3: f9 stc > 4: 5f pop %rdi > 5: 07 (bad) > 6: 00 48 8b add %cl,-0x75(%rax) > 9: 45 90 rex.RB xchg %eax,%r8d > b: 80 48 18 01 orb $0x1,0x18(%rax) > f: 4d 85 e4 test %r12,%r12 > 12: 0f 84 8b fe ff ff je 0xfffffffffffffea3 > 18: 45 84 ed test %r13b,%r13b > 1b: 0f 85 fc 03 00 00 jne 0x41d > 21: 49 8d 7c 24 08 lea 0x8(%r12),%rdi > 26: e8 b5 67 07 00 callq 0x767e0 > 2b:* 41 f6 44 24 08 01 testb $0x1,0x8(%r12) <-- trapping instruction > 31: 0f 84 29 02 00 00 je 0x260 > 37: 83 6d c8 01 subl $0x1,-0x38(%rbp) > 3b: 4c 89 e7 mov %r12,%rdi > 3e: e8 .byte 0xe8 > 3f: bd .byte 0xbd This differs in which functions got inlined (unmap_page_range showing up in place of zap_pte_range), but this is the same "if (PageAnon(page))" that Sasha reported in the "hang in shmem_fallocate" thread on June 26th. I can see what it is now, and here is most of a patch (which I don't expect to satisfy Trinity yet); at this point I think I had better hand it over to Mel, to complete or to discard. [INCOMPLETE PATCH] x86,mm: fix pte_special versus pte_numa Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 at mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels: where zap_pte_range() checks page->mapping to see if PageAnon(page). Those addresses fit struct pages for pfns d2001 and d2000, and in each dump a register or a stack slot showed d2001730 or d2000730: pte flags 0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has a hole between cfffffff and 100000000, which would need special access. Commit c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL pte no longer passes the pte_special() test, so zap_pte_range() goes on to try to access a non-existent struct page. Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). It's unclear why c46a7c817e66 added pte_numa() test to vm_normal_page(), and moved its is_zero_pfn() test from slow to fast path: I suspect both were papering over PROT_NONE issues seen with inadequate pte_special(). Revert vm_normal_page() to how it was before, relying on pte_special(). I find it confusing, that the only example of ARCH_USES_NUMA_PROT_NONE no longer uses PROTNONE for NUMA, but SPECIAL instead: update the asm-generic comment a little, but that config option remains unhelpful. But more seriously, I think this patch is incomplete: aren't there other places which need to be handling PROTNONE along with PRESENT? For example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, but on a PROT_NONE area, I think that will now make it pte_special()? So it ought to clear _PAGE_PROTNONE too. Or maybe we can never pte_mknuma() on a PROT_NONE area - there would be no point? Around here I began to wonder if it was just a mistake to have deserted the PROTNONE for NUMA model: I know Linus had a strong reaction against it, and I've never delved into its drawbacks myself; but bringing yet another (SPECIAL) flag into the game is not an obvious improvement. Should we just revert c46a7c817e66, or would that be a mistake? Let me hand this over to Mel now... Partially-Fixes: c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") Reported-by: Sasha Levin <sasha.levin@oracle.com> Not-yet-Signed-off-by: Hugh Dickins <hughd@google.com> Cc: stable@vger.kernel.org [3.16] --- arch/x86/include/asm/pgtable.h | 9 +++++++-- include/asm-generic/pgtable.h | 6 +++--- mm/memory.c | 7 +++---- 3 files changed, 13 insertions(+), 9 deletions(-) --- v3.16/arch/x86/include/asm/pgtable.h 2014-08-03 15:25:02.000000000 -0700 +++ linux/arch/x86/include/asm/pgtable.h 2014-08-03 17:36:02.364552987 -0700 @@ -131,8 +131,13 @@ static inline int pte_exec(pte_t pte) static inline int pte_special(pte_t pte) { - return (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_SPECIAL)) == - (_PAGE_PRESENT|_PAGE_SPECIAL); + /* + * See CONFIG_NUMA_BALANCING CONFIG_ARCH_USES_NUMA_PROT_NONE pte_numa() + * in include/asm-generic/pgtable.h: on x86 we have _PAGE_BIT_NUMA == + * _PAGE_BIT_GLOBAL+1 == __PAGE_BIT_SOFTW1 == _PAGE_BIT_SPECIAL. + */ + return (pte_flags(pte) & _PAGE_SPECIAL) && + (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_PROTNONE)); } static inline unsigned long pte_pfn(pte_t pte) --- v3.16/include/asm-generic/pgtable.h 2014-08-03 15:25:02.000000000 -0700 +++ linux/include/asm-generic/pgtable.h 2014-08-03 17:36:02.364552987 -0700 @@ -662,9 +662,9 @@ static inline int pmd_trans_unstable(pmd #ifdef CONFIG_NUMA_BALANCING #ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE /* - * _PAGE_NUMA works identical to _PAGE_PROTNONE (it's actually the - * same bit too). It's set only when _PAGE_PRESET is not set and it's - * never set if _PAGE_PRESENT is set. + * _PAGE_NUMA works identically to _PAGE_PROTNONE. + * It is set only when neither _PAGE_PRESENT nor _PAGE_PROTNONE is set. + * This allows it to share a bit set only when present e.g. _PAGE_SPECIAL. * * pte/pmd_present() returns true if pte/pmd_numa returns true. Page * fault triggers on those regions if pte/pmd_numa returns true --- v3.16/mm/memory.c 2014-08-03 15:25:02.000000000 -0700 +++ linux/mm/memory.c 2014-08-03 17:36:02.368552987 -0700 @@ -751,7 +751,7 @@ struct page *vm_normal_page(struct vm_ar unsigned long pfn = pte_pfn(pte); if (HAVE_PTE_SPECIAL) { - if (likely(!pte_special(pte) || pte_numa(pte))) + if (likely(!pte_special(pte))) goto check_pfn; if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)) return NULL; @@ -777,15 +777,14 @@ struct page *vm_normal_page(struct vm_ar } } + if (is_zero_pfn(pfn)) + return NULL; check_pfn: if (unlikely(pfn > highest_memmap_pfn)) { print_bad_pte(vma, addr, pte, NULL); return NULL; } - if (is_zero_pfn(pfn)) - return NULL; - /* * NOTE! We still have PageReserved() pages in the page tables. * eg. VDSO mappings can cause them to exist. -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-08-04 11:40 ` Hugh Dickins @ 2014-08-05 14:44 ` Mel Gorman -1 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-08-05 14:44 UTC (permalink / raw) To: Hugh Dickins Cc: Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov [-- Attachment #1: Type: text/plain, Size: 8333 bytes --] On Mon, Aug 04, 2014 at 04:40:38AM -0700, Hugh Dickins wrote: > On Sat, 2 Aug 2014, Sasha Levin wrote: > > > Hi all, > > > > While fuzzing with trinity inside a KVM tools guest running the latest -next > > kernel, I've stumbled on the following spew: > > > > [ 2957.087977] BUG: unable to handle kernel paging request at ffffea0003480008 > > [ 2957.088008] IP: unmap_page_range (mm/memory.c:1132 mm/memory.c:1256 mm/memory.c:1277 mm/memory.c:1301) > > [ 2957.088024] PGD 7fffc6067 PUD 7fffc5067 PMD 0 > > [ 2957.088041] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > > [ 2957.088087] Dumping ftrace buffer: > > [ 2957.088266] (ftrace buffer empty) > > [ 2957.088279] Modules linked in: > > [ 2957.088293] CPU: 2 PID: 15417 Comm: trinity-c200 Not tainted 3.16.0-rc7-next-20140801-sasha-00047-gd6ce559 #990 > > [ 2957.088301] task: ffff8807a8c50000 ti: ffff880739fb4000 task.ti: ffff880739fb4000 > > [ 2957.088320] RIP: unmap_page_range (mm/memory.c:1132 mm/memory.c:1256 mm/memory.c:1277 mm/memory.c:1301) > > [ 2957.088328] RSP: 0018:ffff880739fb7c58 EFLAGS: 00010246 > > [ 2957.088336] RAX: 0000000000000000 RBX: ffff880eb2bdbed8 RCX: dfff971b42800000 > > [ 2957.088343] RDX: 1ffff100e73f6fc4 RSI: 00007f00e85db000 RDI: ffffea0003480008 > > [ 2957.088350] RBP: ffff880739fb7d58 R08: 0000000000000001 R09: 0000000000b6e000 > > [ 2957.088357] R10: 0000000000000000 R11: 0000000000000001 R12: ffffea0003480000 > > [ 2957.088365] R13: 00000000d2000700 R14: 00007f00e85dc000 R15: 00007f00e85db000 > > [ 2957.088374] FS: 00007f00e85d8700(0000) GS:ffff88177fa00000(0000) knlGS:0000000000000000 > > [ 2957.088381] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [ 2957.088387] CR2: ffffea0003480008 CR3: 00000007a802a000 CR4: 00000000000006a0 > > [ 2957.088406] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > [ 2957.088413] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 > > [ 2957.088416] Stack: > > [ 2957.088432] ffff88171726d570 0000000000000010 0000000000000008 00000000d2000730 > > [ 2957.088450] 0000000019d00250 00007f00e85dc000 ffff880f9d311900 ffff880739fb7e20 > > [ 2957.088466] ffff8807a8c507a0 ffff8807a8c50000 ffff8807a75fe000 ffff8807ceaa7a10 > > [ 2957.088469] Call Trace: > > [ 2957.088490] unmap_single_vma (mm/memory.c:1348) > > [ 2957.088505] unmap_vmas (mm/memory.c:1375 (discriminator 3)) > > [ 2957.088520] unmap_region (mm/mmap.c:2386 (discriminator 4)) > > [ 2957.088542] ? vma_rb_erase (mm/mmap.c:454 include/linux/rbtree_augmented.h:219 include/linux/rbtree_augmented.h:227 mm/mmap.c:493) > > [ 2957.088559] ? vmacache_update (mm/vmacache.c:61) > > [ 2957.088572] do_munmap (mm/mmap.c:2581) > > [ 2957.088583] vm_munmap (mm/mmap.c:2596) > > [ 2957.088595] SyS_munmap (mm/mmap.c:2601) > > [ 2957.088616] tracesys (arch/x86/kernel/entry_64.S:541) > > [ 2957.088770] Code: ff ff e8 f9 5f 07 00 48 8b 45 90 80 48 18 01 4d 85 e4 0f 84 8b fe ff ff 45 84 ed 0f 85 fc 03 00 00 49 8d 7c 24 08 e8 b5 67 07 00 <41> f6 44 24 08 01 0f 84 29 02 00 00 83 6d c8 01 4c 89 e7 e8 bd > > All code > > ======== > > 0: ff (bad) > > 1: ff e8 ljmpq *<internal disassembler error> > > 3: f9 stc > > 4: 5f pop %rdi > > 5: 07 (bad) > > 6: 00 48 8b add %cl,-0x75(%rax) > > 9: 45 90 rex.RB xchg %eax,%r8d > > b: 80 48 18 01 orb $0x1,0x18(%rax) > > f: 4d 85 e4 test %r12,%r12 > > 12: 0f 84 8b fe ff ff je 0xfffffffffffffea3 > > 18: 45 84 ed test %r13b,%r13b > > 1b: 0f 85 fc 03 00 00 jne 0x41d > > 21: 49 8d 7c 24 08 lea 0x8(%r12),%rdi > > 26: e8 b5 67 07 00 callq 0x767e0 > > 2b:* 41 f6 44 24 08 01 testb $0x1,0x8(%r12) <-- trapping instruction > > 31: 0f 84 29 02 00 00 je 0x260 > > 37: 83 6d c8 01 subl $0x1,-0x38(%rbp) > > 3b: 4c 89 e7 mov %r12,%rdi > > 3e: e8 .byte 0xe8 > > 3f: bd .byte 0xbd > > This differs in which functions got inlined (unmap_page_range showing up > in place of zap_pte_range), but this is the same "if (PageAnon(page))" > that Sasha reported in the "hang in shmem_fallocate" thread on June 26th. > > I can see what it is now, and here is most of a patch (which I don't > expect to satisfy Trinity yet); at this point I think I had better > hand it over to Mel, to complete or to discard. > > [INCOMPLETE PATCH] x86,mm: fix pte_special versus pte_numa > > Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 > at mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels: > where zap_pte_range() checks page->mapping to see if PageAnon(page). > > Those addresses fit struct pages for pfns d2001 and d2000, and in each > dump a register or a stack slot showed d2001730 or d2000730: pte flags > 0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has > a hole between cfffffff and 100000000, which would need special access. > > Commit c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on > the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL > pte no longer passes the pte_special() test, so zap_pte_range() goes on > to try to access a non-existent struct page. > :( > Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) > to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). > > It's unclear why c46a7c817e66 added pte_numa() test to vm_normal_page(), > and moved its is_zero_pfn() test from slow to fast path: I suspect both > were papering over PROT_NONE issues seen with inadequate pte_special(). > Revert vm_normal_page() to how it was before, relying on pte_special(). > Rather than answering directly I updated your changelog Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). A hint that this was a problem was that c46a7c817e66 added pte_numa() test to vm_normal_page(), and moved its is_zero_pfn() test from slow to fast path: This was papering over a pte_special() snag when the zero page was encountered during zap. This patch reverts vm_normal_page() to how it was before, relying on pte_special(). > I find it confusing, that the only example of ARCH_USES_NUMA_PROT_NONE > no longer uses PROTNONE for NUMA, but SPECIAL instead: update the > asm-generic comment a little, but that config option remains unhelpful. > ARCH_USES_NUMA_PROT_NONE should have been sent to the farm at the same time as that patch and by rights unified with the powerpc helpers. With the new _PAGE_NUMA bit, there is no reason they should have different implementations of pte_numa and related functions. Unfortunately unifying them is a little problematic due to differences in fundamental types. It could be done with #defines but I'm attaching a preliminary prototype to illustrate the issue. > But more seriously, I think this patch is incomplete: aren't there > other places which need to be handling PROTNONE along with PRESENT? > For example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, > but on a PROT_NONE area, I think that will now make it pte_special()? > So it ought to clear _PAGE_PROTNONE too. Or maybe we can never > pte_mknuma() on a PROT_NONE area - there would be no point? > We are depending on the fact that inaccessible VMAs are skipped by the NUMA hinting scanner. > Around here I began to wonder if it was just a mistake to have deserted > the PROTNONE for NUMA model: I know Linus had a strong reaction against > it, and I've never delved into its drawbacks myself; but bringing yet > another (SPECIAL) flag into the game is not an obvious improvement. > Should we just revert c46a7c817e66, or would that be a mistake? > It's replacing one type of complexity with another. The downside is that _PAGE_NUMA == _PAGE_PROTNONE puts subtle traps all over the core for powerpc to fall foul of. I'm attaching a preliminary pair of patches. The first which deals with ARCH_USES_NUMA_PROT_NONE and the second which is yours with a revised changelog. I'm adding Aneesh to the cc to look at the powerpc portion of the first patch. -- Mel Gorman SUSE Labs [-- Attachment #2: 0001 --] [-- Type: text/plain, Size: 7777 bytes --] >From d0c77a2b497da46c52792ead066d461e5111a594 Mon Sep 17 00:00:00 2001 From: Mel Gorman <mgorman@suse.de> Date: Tue, 5 Aug 2014 12:06:50 +0100 Subject: [PATCH] mm: Remove misleading ARCH_USES_NUMA_PROT_NONE ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented _PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting fault scanner. This was found to be conceptually confusing with a lot of implicit assumptions and it was asked that an alternative be found. Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap PTE bits and shrunk the maximum possible swap size but it did not go far enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA but the relics still exist. This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary duplication in powerpc vs the generic implementation by defining the types the core NUMA helpers expected to exist from x86 with their ppc64 equivalent. The unification for ppc64 is less than ideal because types do not exist that the "generic" code expects to. This patch works around the problem but it would be preferred if the powerpc people would look at this to see if they have opinions on what might suit them better. Signed-off-by: Mel Gorman <mgorman@suse.de> --- arch/powerpc/include/asm/pgtable.h | 55 ++++++++------------------------------ arch/x86/Kconfig | 1 - include/asm-generic/pgtable.h | 35 ++++++++++++------------ init/Kconfig | 11 -------- 4 files changed, 29 insertions(+), 73 deletions(-) diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h index d98c1ec..47d3f8f 100644 --- a/arch/powerpc/include/asm/pgtable.h +++ b/arch/powerpc/include/asm/pgtable.h @@ -38,7 +38,6 @@ static inline int pte_none(pte_t pte) { return (pte_val(pte) & ~_PTE_NONE_MASK) static inline pgprot_t pte_pgprot(pte_t pte) { return __pgprot(pte_val(pte) & PAGE_PROT_BITS); } #ifdef CONFIG_NUMA_BALANCING - static inline int pte_present(pte_t pte) { return pte_val(pte) & (_PAGE_PRESENT | _PAGE_NUMA); @@ -50,37 +49,6 @@ static inline int pte_present_nonuma(pte_t pte) return pte_val(pte) & (_PAGE_PRESENT); } -#define pte_numa pte_numa -static inline int pte_numa(pte_t pte) -{ - return (pte_val(pte) & - (_PAGE_NUMA|_PAGE_PRESENT)) == _PAGE_NUMA; -} - -#define pte_mknonnuma pte_mknonnuma -static inline pte_t pte_mknonnuma(pte_t pte) -{ - pte_val(pte) &= ~_PAGE_NUMA; - pte_val(pte) |= _PAGE_PRESENT | _PAGE_ACCESSED; - return pte; -} - -#define pte_mknuma pte_mknuma -static inline pte_t pte_mknuma(pte_t pte) -{ - /* - * We should not set _PAGE_NUMA on non present ptes. Also clear the - * present bit so that hash_page will return 1 and we collect this - * as numa fault. - */ - if (pte_present(pte)) { - pte_val(pte) |= _PAGE_NUMA; - pte_val(pte) &= ~_PAGE_PRESENT; - } else - VM_BUG_ON(1); - return pte; -} - #define ptep_set_numa ptep_set_numa static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, pte_t *ptep) @@ -92,12 +60,6 @@ static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, return; } -#define pmd_numa pmd_numa -static inline int pmd_numa(pmd_t pmd) -{ - return pte_numa(pmd_pte(pmd)); -} - #define pmdp_set_numa pmdp_set_numa static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp) @@ -109,16 +71,21 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, return; } -#define pmd_mknonnuma pmd_mknonnuma -static inline pmd_t pmd_mknonnuma(pmd_t pmd) +/* + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist + * which was inherited from x86. For the purposes of powerpc pte_basic_t is + * equivalent + */ +#define pteval_t pte_basic_t +#define pmdval_t pmd_t +static inline pteval_t pte_flags(pte_t pte) { - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); + return pte_val(pte) & PAGE_PROT_BITS; } -#define pmd_mknuma pmd_mknuma -static inline pmd_t pmd_mknuma(pmd_t pmd) +static inline pteval_t pmd_flags(pte_t pte) { - return pte_pmd(pte_mknuma(pmd_pte(pmd))); + return pmd_val(pte) & PAGE_PROT_BITS; } # else diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index d24887b..0a3f32b 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -28,7 +28,6 @@ config X86 select HAVE_UNSTABLE_SCHED_CLOCK select ARCH_SUPPORTS_NUMA_BALANCING if X86_64 select ARCH_SUPPORTS_INT128 if X86_64 - select ARCH_WANTS_PROT_NUMA_PROT_NONE select HAVE_IDE select HAVE_OPROFILE select HAVE_PCSPKR_PLATFORM diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h index 53b2acc..53294fb 100644 --- a/include/asm-generic/pgtable.h +++ b/include/asm-generic/pgtable.h @@ -660,12 +660,21 @@ static inline int pmd_trans_unstable(pmd_t *pmd) } #ifdef CONFIG_NUMA_BALANCING -#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE + +/* + * _PAGE_NUMA distinguishes between an unmapped page table entry, an entry that + * is protected for PROT_NONE and a NUMA hinting fault entry. If the + * architecture defines __PAGE_PROTNONE then take it into account. As this is + * not universally the case we are relying on the NUMA hinting scanner to skip + * inaccessible VMAs. + */ +#ifdef _PAGE_PROTNONE +#define _PAGE_NUMA_PROTNONE _PAGE_PROTNONE +#else +#define _PAGE_NUMA_PROTNONE 0 +#endif + /* - * _PAGE_NUMA works identical to _PAGE_PROTNONE (it's actually the - * same bit too). It's set only when _PAGE_PRESET is not set and it's - * never set if _PAGE_PRESENT is set. - * * pte/pmd_present() returns true if pte/pmd_numa returns true. Page * fault triggers on those regions if pte/pmd_numa returns true * (because _PAGE_PRESENT is not set). @@ -674,7 +683,7 @@ static inline int pmd_trans_unstable(pmd_t *pmd) static inline int pte_numa(pte_t pte) { return (pte_flags(pte) & - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; + (_PAGE_NUMA|_PAGE_NUMA_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; } #endif @@ -682,7 +691,7 @@ static inline int pte_numa(pte_t pte) static inline int pmd_numa(pmd_t pmd) { return (pmd_flags(pmd) & - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; + (_PAGE_NUMA|_PAGE_NUMA_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; } #endif @@ -722,6 +731,8 @@ static inline pte_t pte_mknuma(pte_t pte) { pteval_t val = pte_val(pte); + VM_BUG_ON(!pte_present(pte)); + val &= ~_PAGE_PRESENT; val |= _PAGE_NUMA; @@ -765,16 +776,6 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, } #endif #else -extern int pte_numa(pte_t pte); -extern int pmd_numa(pmd_t pmd); -extern pte_t pte_mknonnuma(pte_t pte); -extern pmd_t pmd_mknonnuma(pmd_t pmd); -extern pte_t pte_mknuma(pte_t pte); -extern pmd_t pmd_mknuma(pmd_t pmd); -extern void ptep_set_numa(struct mm_struct *mm, unsigned long addr, pte_t *ptep); -extern void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp); -#endif /* CONFIG_ARCH_USES_NUMA_PROT_NONE */ -#else static inline int pmd_numa(pmd_t pmd) { return 0; diff --git a/init/Kconfig b/init/Kconfig index 9d76b99..60fa415 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -844,17 +844,6 @@ config ARCH_SUPPORTS_INT128 config ARCH_WANT_NUMA_VARIABLE_LOCALITY bool -# -# For architectures that are willing to define _PAGE_NUMA as _PAGE_PROTNONE -config ARCH_WANTS_PROT_NUMA_PROT_NONE - bool - -config ARCH_USES_NUMA_PROT_NONE - bool - default y - depends on ARCH_WANTS_PROT_NUMA_PROT_NONE - depends on NUMA_BALANCING - config NUMA_BALANCING_DEFAULT_ENABLED bool "Automatically enable NUMA aware memory/task placement" default y [-- Attachment #3: 0002 --] [-- Type: text/plain, Size: 3946 bytes --] >From aacf36ad7b4bbe6d9f0afac83e8ca9b0666cb9f0 Mon Sep 17 00:00:00 2001 From: Hugh Dickins <hughd@google.com> Date: Tue, 5 Aug 2014 11:33:59 +0100 Subject: [PATCH] x86,mm: fix pte_special versus pte_numa Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 at mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels: where zap_pte_range() checks page->mapping to see if PageAnon(page). Those addresses fit struct pages for pfns d2001 and d2000, and in each dump a register or a stack slot showed d2001730 or d2000730: pte flags 0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has a hole between cfffffff and 100000000, which would need special access. Commit c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL pte no longer passes the pte_special() test, so zap_pte_range() goes on to try to access a non-existent struct page. Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). A hint that this was a problem was that c46a7c817e66 added pte_numa() test to vm_normal_page(), and moved its is_zero_pfn() test from slow to fast path: This was papering over a pte_special() snag when the zero page was encountered during zap. This patch reverts vm_normal_page() to how it was before, relying on pte_special(). It still appears that this patch may be incomplete: aren't there other places which need to be handling PROTNONE along with PRESENT? For example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, but on a PROT_NONE area, that would make it it pte_special(). This is side-stepped by the fact that NUMA hinting faults skiped PROT_NONE VMAs and there are no grounds where a NUMA hinting fault on a PROT_NONE VMA would be interesting. Partially-Fixes: c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") Reported-by: Sasha Levin <sasha.levin@oracle.com> Not-yet-Signed-off-by: Hugh Dickins <hughd@google.com> Not-yet-Signed-off-by: Mel Gorman <mgorman@suse.de> Cc: stable@vger.kernel.org [3.16] --- arch/x86/include/asm/pgtable.h | 9 +++++++-- mm/memory.c | 7 +++---- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h index 0ec0560..230b811 100644 --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -131,8 +131,13 @@ static inline int pte_exec(pte_t pte) static inline int pte_special(pte_t pte) { - return (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_SPECIAL)) == - (_PAGE_PRESENT|_PAGE_SPECIAL); + /* + * See CONFIG_NUMA_BALANCING CONFIG_ARCH_USES_NUMA_PROT_NONE pte_numa() + * in include/asm-generic/pgtable.h: on x86 we have _PAGE_BIT_NUMA == + * _PAGE_BIT_GLOBAL+1 == __PAGE_BIT_SOFTW1 == _PAGE_BIT_SPECIAL. + */ + return (pte_flags(pte) & _PAGE_SPECIAL) && + (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_PROTNONE)); } static inline unsigned long pte_pfn(pte_t pte) diff --git a/mm/memory.c b/mm/memory.c index 8b44f76..0a21f3d 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -751,7 +751,7 @@ struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn = pte_pfn(pte); if (HAVE_PTE_SPECIAL) { - if (likely(!pte_special(pte) || pte_numa(pte))) + if (likely(!pte_special(pte))) goto check_pfn; if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)) return NULL; @@ -777,15 +777,14 @@ struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr, } } + if (is_zero_pfn(pfn)) + return NULL; check_pfn: if (unlikely(pfn > highest_memmap_pfn)) { print_bad_pte(vma, addr, pte, NULL); return NULL; } - if (is_zero_pfn(pfn)) - return NULL; - /* * NOTE! We still have PageReserved() pages in the page tables. * eg. VDSO mappings can cause them to exist. ^ permalink raw reply related [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-05 14:44 ` Mel Gorman 0 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-08-05 14:44 UTC (permalink / raw) To: Hugh Dickins Cc: Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov [-- Attachment #1: Type: text/plain, Size: 8333 bytes --] On Mon, Aug 04, 2014 at 04:40:38AM -0700, Hugh Dickins wrote: > On Sat, 2 Aug 2014, Sasha Levin wrote: > > > Hi all, > > > > While fuzzing with trinity inside a KVM tools guest running the latest -next > > kernel, I've stumbled on the following spew: > > > > [ 2957.087977] BUG: unable to handle kernel paging request at ffffea0003480008 > > [ 2957.088008] IP: unmap_page_range (mm/memory.c:1132 mm/memory.c:1256 mm/memory.c:1277 mm/memory.c:1301) > > [ 2957.088024] PGD 7fffc6067 PUD 7fffc5067 PMD 0 > > [ 2957.088041] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > > [ 2957.088087] Dumping ftrace buffer: > > [ 2957.088266] (ftrace buffer empty) > > [ 2957.088279] Modules linked in: > > [ 2957.088293] CPU: 2 PID: 15417 Comm: trinity-c200 Not tainted 3.16.0-rc7-next-20140801-sasha-00047-gd6ce559 #990 > > [ 2957.088301] task: ffff8807a8c50000 ti: ffff880739fb4000 task.ti: ffff880739fb4000 > > [ 2957.088320] RIP: unmap_page_range (mm/memory.c:1132 mm/memory.c:1256 mm/memory.c:1277 mm/memory.c:1301) > > [ 2957.088328] RSP: 0018:ffff880739fb7c58 EFLAGS: 00010246 > > [ 2957.088336] RAX: 0000000000000000 RBX: ffff880eb2bdbed8 RCX: dfff971b42800000 > > [ 2957.088343] RDX: 1ffff100e73f6fc4 RSI: 00007f00e85db000 RDI: ffffea0003480008 > > [ 2957.088350] RBP: ffff880739fb7d58 R08: 0000000000000001 R09: 0000000000b6e000 > > [ 2957.088357] R10: 0000000000000000 R11: 0000000000000001 R12: ffffea0003480000 > > [ 2957.088365] R13: 00000000d2000700 R14: 00007f00e85dc000 R15: 00007f00e85db000 > > [ 2957.088374] FS: 00007f00e85d8700(0000) GS:ffff88177fa00000(0000) knlGS:0000000000000000 > > [ 2957.088381] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [ 2957.088387] CR2: ffffea0003480008 CR3: 00000007a802a000 CR4: 00000000000006a0 > > [ 2957.088406] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > [ 2957.088413] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 > > [ 2957.088416] Stack: > > [ 2957.088432] ffff88171726d570 0000000000000010 0000000000000008 00000000d2000730 > > [ 2957.088450] 0000000019d00250 00007f00e85dc000 ffff880f9d311900 ffff880739fb7e20 > > [ 2957.088466] ffff8807a8c507a0 ffff8807a8c50000 ffff8807a75fe000 ffff8807ceaa7a10 > > [ 2957.088469] Call Trace: > > [ 2957.088490] unmap_single_vma (mm/memory.c:1348) > > [ 2957.088505] unmap_vmas (mm/memory.c:1375 (discriminator 3)) > > [ 2957.088520] unmap_region (mm/mmap.c:2386 (discriminator 4)) > > [ 2957.088542] ? vma_rb_erase (mm/mmap.c:454 include/linux/rbtree_augmented.h:219 include/linux/rbtree_augmented.h:227 mm/mmap.c:493) > > [ 2957.088559] ? vmacache_update (mm/vmacache.c:61) > > [ 2957.088572] do_munmap (mm/mmap.c:2581) > > [ 2957.088583] vm_munmap (mm/mmap.c:2596) > > [ 2957.088595] SyS_munmap (mm/mmap.c:2601) > > [ 2957.088616] tracesys (arch/x86/kernel/entry_64.S:541) > > [ 2957.088770] Code: ff ff e8 f9 5f 07 00 48 8b 45 90 80 48 18 01 4d 85 e4 0f 84 8b fe ff ff 45 84 ed 0f 85 fc 03 00 00 49 8d 7c 24 08 e8 b5 67 07 00 <41> f6 44 24 08 01 0f 84 29 02 00 00 83 6d c8 01 4c 89 e7 e8 bd > > All code > > ======== > > 0: ff (bad) > > 1: ff e8 ljmpq *<internal disassembler error> > > 3: f9 stc > > 4: 5f pop %rdi > > 5: 07 (bad) > > 6: 00 48 8b add %cl,-0x75(%rax) > > 9: 45 90 rex.RB xchg %eax,%r8d > > b: 80 48 18 01 orb $0x1,0x18(%rax) > > f: 4d 85 e4 test %r12,%r12 > > 12: 0f 84 8b fe ff ff je 0xfffffffffffffea3 > > 18: 45 84 ed test %r13b,%r13b > > 1b: 0f 85 fc 03 00 00 jne 0x41d > > 21: 49 8d 7c 24 08 lea 0x8(%r12),%rdi > > 26: e8 b5 67 07 00 callq 0x767e0 > > 2b:* 41 f6 44 24 08 01 testb $0x1,0x8(%r12) <-- trapping instruction > > 31: 0f 84 29 02 00 00 je 0x260 > > 37: 83 6d c8 01 subl $0x1,-0x38(%rbp) > > 3b: 4c 89 e7 mov %r12,%rdi > > 3e: e8 .byte 0xe8 > > 3f: bd .byte 0xbd > > This differs in which functions got inlined (unmap_page_range showing up > in place of zap_pte_range), but this is the same "if (PageAnon(page))" > that Sasha reported in the "hang in shmem_fallocate" thread on June 26th. > > I can see what it is now, and here is most of a patch (which I don't > expect to satisfy Trinity yet); at this point I think I had better > hand it over to Mel, to complete or to discard. > > [INCOMPLETE PATCH] x86,mm: fix pte_special versus pte_numa > > Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 > at mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels: > where zap_pte_range() checks page->mapping to see if PageAnon(page). > > Those addresses fit struct pages for pfns d2001 and d2000, and in each > dump a register or a stack slot showed d2001730 or d2000730: pte flags > 0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has > a hole between cfffffff and 100000000, which would need special access. > > Commit c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on > the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL > pte no longer passes the pte_special() test, so zap_pte_range() goes on > to try to access a non-existent struct page. > :( > Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) > to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). > > It's unclear why c46a7c817e66 added pte_numa() test to vm_normal_page(), > and moved its is_zero_pfn() test from slow to fast path: I suspect both > were papering over PROT_NONE issues seen with inadequate pte_special(). > Revert vm_normal_page() to how it was before, relying on pte_special(). > Rather than answering directly I updated your changelog Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). A hint that this was a problem was that c46a7c817e66 added pte_numa() test to vm_normal_page(), and moved its is_zero_pfn() test from slow to fast path: This was papering over a pte_special() snag when the zero page was encountered during zap. This patch reverts vm_normal_page() to how it was before, relying on pte_special(). > I find it confusing, that the only example of ARCH_USES_NUMA_PROT_NONE > no longer uses PROTNONE for NUMA, but SPECIAL instead: update the > asm-generic comment a little, but that config option remains unhelpful. > ARCH_USES_NUMA_PROT_NONE should have been sent to the farm at the same time as that patch and by rights unified with the powerpc helpers. With the new _PAGE_NUMA bit, there is no reason they should have different implementations of pte_numa and related functions. Unfortunately unifying them is a little problematic due to differences in fundamental types. It could be done with #defines but I'm attaching a preliminary prototype to illustrate the issue. > But more seriously, I think this patch is incomplete: aren't there > other places which need to be handling PROTNONE along with PRESENT? > For example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, > but on a PROT_NONE area, I think that will now make it pte_special()? > So it ought to clear _PAGE_PROTNONE too. Or maybe we can never > pte_mknuma() on a PROT_NONE area - there would be no point? > We are depending on the fact that inaccessible VMAs are skipped by the NUMA hinting scanner. > Around here I began to wonder if it was just a mistake to have deserted > the PROTNONE for NUMA model: I know Linus had a strong reaction against > it, and I've never delved into its drawbacks myself; but bringing yet > another (SPECIAL) flag into the game is not an obvious improvement. > Should we just revert c46a7c817e66, or would that be a mistake? > It's replacing one type of complexity with another. The downside is that _PAGE_NUMA == _PAGE_PROTNONE puts subtle traps all over the core for powerpc to fall foul of. I'm attaching a preliminary pair of patches. The first which deals with ARCH_USES_NUMA_PROT_NONE and the second which is yours with a revised changelog. I'm adding Aneesh to the cc to look at the powerpc portion of the first patch. -- Mel Gorman SUSE Labs [-- Attachment #2: 0001 --] [-- Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-08-05 14:44 ` Mel Gorman @ 2014-08-06 0:42 ` Hugh Dickins -1 siblings, 0 replies; 86+ messages in thread From: Hugh Dickins @ 2014-08-06 0:42 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Tue, 5 Aug 2014, Mel Gorman wrote: > On Mon, Aug 04, 2014 at 04:40:38AM -0700, Hugh Dickins wrote: > > > > [INCOMPLETE PATCH] x86,mm: fix pte_special versus pte_numa > > > > Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 > > at mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels: > > where zap_pte_range() checks page->mapping to see if PageAnon(page). > > > > Those addresses fit struct pages for pfns d2001 and d2000, and in each > > dump a register or a stack slot showed d2001730 or d2000730: pte flags > > 0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has > > a hole between cfffffff and 100000000, which would need special access. > > > > Commit c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on > > the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL > > pte no longer passes the pte_special() test, so zap_pte_range() goes on > > to try to access a non-existent struct page. > > > > :( > > > Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) > > to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). > > > > It's unclear why c46a7c817e66 added pte_numa() test to vm_normal_page(), > > and moved its is_zero_pfn() test from slow to fast path: I suspect both > > were papering over PROT_NONE issues seen with inadequate pte_special(). > > Revert vm_normal_page() to how it was before, relying on pte_special(). > > > > Rather than answering directly I updated your changelog > > Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) > to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). > > A hint that this was a problem was that c46a7c817e66 added pte_numa() > test to vm_normal_page(), and moved its is_zero_pfn() test from slow to > fast path: This was papering over a pte_special() snag when the zero > page was encountered during zap. This patch reverts vm_normal_page() > to how it was before, relying on pte_special(). Thanks, that's fine. > > > I find it confusing, that the only example of ARCH_USES_NUMA_PROT_NONE > > no longer uses PROTNONE for NUMA, but SPECIAL instead: update the > > asm-generic comment a little, but that config option remains unhelpful. > > > > ARCH_USES_NUMA_PROT_NONE should have been sent to the farm at the same time > as that patch and by rights unified with the powerpc helpers. With the new > _PAGE_NUMA bit, there is no reason they should have different implementations > of pte_numa and related functions. Unfortunately unifying them is a little > problematic due to differences in fundamental types. It could be done with > #defines but I'm attaching a preliminary prototype to illustrate the issue. > > > But more seriously, I think this patch is incomplete: aren't there > > other places which need to be handling PROTNONE along with PRESENT? > > For example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, > > but on a PROT_NONE area, I think that will now make it pte_special()? > > So it ought to clear _PAGE_PROTNONE too. Or maybe we can never > > pte_mknuma() on a PROT_NONE area - there would be no point? > > > > We are depending on the fact that inaccessible VMAs are skipped by the > NUMA hinting scanner. Ah, okay. And the other way round (mprotecting to PROT_NONE an area which already contains _PAGE_NUMA ptes) already looked safe to me. > > > Around here I began to wonder if it was just a mistake to have deserted > > the PROTNONE for NUMA model: I know Linus had a strong reaction against > > it, and I've never delved into its drawbacks myself; but bringing yet > > another (SPECIAL) flag into the game is not an obvious improvement. > > Should we just revert c46a7c817e66, or would that be a mistake? > > > > It's replacing one type of complexity with another. The downside is that > _PAGE_NUMA == _PAGE_PROTNONE puts subtle traps all over the core for > powerpc to fall foul of. Okay. > > I'm attaching a preliminary pair of patches. The first which deals with > ARCH_USES_NUMA_PROT_NONE and the second which is yours with a revised > changelog. I'm adding Aneesh to the cc to look at the powerpc portion of > the first patch. Thanks a lot, Mel. I am surprised by the ordering, but perhaps you meant nothing by it. Isn't the first one a welcome but optional cleanup, and the second one a fix that we need in 3.16-stable? Or does the fix actually depend in some unstated way upon the cleanup, in powerpc-land perhaps? Aside from that, for the first patch: yes, I heartily approve of the disappearance of CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE and CONFIG_ARCH_USES_NUMA_PROT_NONE. If you wish, add Acked-by: Hugh Dickins <hughd@google.com> but of course it's really Aneesh and powerpc who are the test of it. One thing I did wonder, though: at first I was reassured by the VM_BUG_ON(!pte_present(pte)) you add to pte_mknuma(); but then thought it would be better as VM_BUG_ON(!(val & _PAGE_PRESENT)), being stronger - asserting that indeed we do not put NUMA hints on PROT_NONE areas. (But I have not tested, perhaps such a VM_BUG_ON would actually fire.) And in the second patch, a few trivial edits: > It still appears that this patch may be incomplete: aren't there other > places which need to be handling PROTNONE along with PRESENT? For example, > pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, but on a PROT_NONE > area, that would make it it pte_special(). This is side-stepped by the fact s/it it/it/ > that NUMA hinting faults skiped PROT_NONE VMAs and there are no grounds s/skiped/skip/ > where a NUMA hinting fault on a PROT_NONE VMA would be interesting. > > Partially-Fixes: c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") s/Partially-// > Reported-by: Sasha Levin <sasha.levin@oracle.com> > Not-yet-Signed-off-by: Hugh Dickins <hughd@google.com> s/Not-yet-// > Not-yet-Signed-off-by: Mel Gorman <mgorman@suse.de> Ditto I must leave to you! > Cc: stable@vger.kernel.org [3.16] > --- > arch/x86/include/asm/pgtable.h | 9 +++++++-- > mm/memory.c | 7 +++---- > 2 files changed, 10 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h > index 0ec0560..230b811 100644 > --- a/arch/x86/include/asm/pgtable.h > +++ b/arch/x86/include/asm/pgtable.h > @@ -131,8 +131,13 @@ static inline int pte_exec(pte_t pte) > > static inline int pte_special(pte_t pte) > { > - return (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_SPECIAL)) == > - (_PAGE_PRESENT|_PAGE_SPECIAL); > + /* > + * See CONFIG_NUMA_BALANCING CONFIG_ARCH_USES_NUMA_PROT_NONE pte_numa() s/CONFIG_ARCH_USES_NUMA_PROT_NONE // even if you do end up reordering this patch before the other. Thanks! Hugh ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-06 0:42 ` Hugh Dickins 0 siblings, 0 replies; 86+ messages in thread From: Hugh Dickins @ 2014-08-06 0:42 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Tue, 5 Aug 2014, Mel Gorman wrote: > On Mon, Aug 04, 2014 at 04:40:38AM -0700, Hugh Dickins wrote: > > > > [INCOMPLETE PATCH] x86,mm: fix pte_special versus pte_numa > > > > Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 > > at mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels: > > where zap_pte_range() checks page->mapping to see if PageAnon(page). > > > > Those addresses fit struct pages for pfns d2001 and d2000, and in each > > dump a register or a stack slot showed d2001730 or d2000730: pte flags > > 0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has > > a hole between cfffffff and 100000000, which would need special access. > > > > Commit c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on > > the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL > > pte no longer passes the pte_special() test, so zap_pte_range() goes on > > to try to access a non-existent struct page. > > > > :( > > > Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) > > to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). > > > > It's unclear why c46a7c817e66 added pte_numa() test to vm_normal_page(), > > and moved its is_zero_pfn() test from slow to fast path: I suspect both > > were papering over PROT_NONE issues seen with inadequate pte_special(). > > Revert vm_normal_page() to how it was before, relying on pte_special(). > > > > Rather than answering directly I updated your changelog > > Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) > to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). > > A hint that this was a problem was that c46a7c817e66 added pte_numa() > test to vm_normal_page(), and moved its is_zero_pfn() test from slow to > fast path: This was papering over a pte_special() snag when the zero > page was encountered during zap. This patch reverts vm_normal_page() > to how it was before, relying on pte_special(). Thanks, that's fine. > > > I find it confusing, that the only example of ARCH_USES_NUMA_PROT_NONE > > no longer uses PROTNONE for NUMA, but SPECIAL instead: update the > > asm-generic comment a little, but that config option remains unhelpful. > > > > ARCH_USES_NUMA_PROT_NONE should have been sent to the farm at the same time > as that patch and by rights unified with the powerpc helpers. With the new > _PAGE_NUMA bit, there is no reason they should have different implementations > of pte_numa and related functions. Unfortunately unifying them is a little > problematic due to differences in fundamental types. It could be done with > #defines but I'm attaching a preliminary prototype to illustrate the issue. > > > But more seriously, I think this patch is incomplete: aren't there > > other places which need to be handling PROTNONE along with PRESENT? > > For example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, > > but on a PROT_NONE area, I think that will now make it pte_special()? > > So it ought to clear _PAGE_PROTNONE too. Or maybe we can never > > pte_mknuma() on a PROT_NONE area - there would be no point? > > > > We are depending on the fact that inaccessible VMAs are skipped by the > NUMA hinting scanner. Ah, okay. And the other way round (mprotecting to PROT_NONE an area which already contains _PAGE_NUMA ptes) already looked safe to me. > > > Around here I began to wonder if it was just a mistake to have deserted > > the PROTNONE for NUMA model: I know Linus had a strong reaction against > > it, and I've never delved into its drawbacks myself; but bringing yet > > another (SPECIAL) flag into the game is not an obvious improvement. > > Should we just revert c46a7c817e66, or would that be a mistake? > > > > It's replacing one type of complexity with another. The downside is that > _PAGE_NUMA == _PAGE_PROTNONE puts subtle traps all over the core for > powerpc to fall foul of. Okay. > > I'm attaching a preliminary pair of patches. The first which deals with > ARCH_USES_NUMA_PROT_NONE and the second which is yours with a revised > changelog. I'm adding Aneesh to the cc to look at the powerpc portion of > the first patch. Thanks a lot, Mel. I am surprised by the ordering, but perhaps you meant nothing by it. Isn't the first one a welcome but optional cleanup, and the second one a fix that we need in 3.16-stable? Or does the fix actually depend in some unstated way upon the cleanup, in powerpc-land perhaps? Aside from that, for the first patch: yes, I heartily approve of the disappearance of CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE and CONFIG_ARCH_USES_NUMA_PROT_NONE. If you wish, add Acked-by: Hugh Dickins <hughd@google.com> but of course it's really Aneesh and powerpc who are the test of it. One thing I did wonder, though: at first I was reassured by the VM_BUG_ON(!pte_present(pte)) you add to pte_mknuma(); but then thought it would be better as VM_BUG_ON(!(val & _PAGE_PRESENT)), being stronger - asserting that indeed we do not put NUMA hints on PROT_NONE areas. (But I have not tested, perhaps such a VM_BUG_ON would actually fire.) And in the second patch, a few trivial edits: > It still appears that this patch may be incomplete: aren't there other > places which need to be handling PROTNONE along with PRESENT? For example, > pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, but on a PROT_NONE > area, that would make it it pte_special(). This is side-stepped by the fact s/it it/it/ > that NUMA hinting faults skiped PROT_NONE VMAs and there are no grounds s/skiped/skip/ > where a NUMA hinting fault on a PROT_NONE VMA would be interesting. > > Partially-Fixes: c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") s/Partially-// > Reported-by: Sasha Levin <sasha.levin@oracle.com> > Not-yet-Signed-off-by: Hugh Dickins <hughd@google.com> s/Not-yet-// > Not-yet-Signed-off-by: Mel Gorman <mgorman@suse.de> Ditto I must leave to you! > Cc: stable@vger.kernel.org [3.16] > --- > arch/x86/include/asm/pgtable.h | 9 +++++++-- > mm/memory.c | 7 +++---- > 2 files changed, 10 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h > index 0ec0560..230b811 100644 > --- a/arch/x86/include/asm/pgtable.h > +++ b/arch/x86/include/asm/pgtable.h > @@ -131,8 +131,13 @@ static inline int pte_exec(pte_t pte) > > static inline int pte_special(pte_t pte) > { > - return (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_SPECIAL)) == > - (_PAGE_PRESENT|_PAGE_SPECIAL); > + /* > + * See CONFIG_NUMA_BALANCING CONFIG_ARCH_USES_NUMA_PROT_NONE pte_numa() s/CONFIG_ARCH_USES_NUMA_PROT_NONE // even if you do end up reordering this patch before the other. Thanks! Hugh -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-08-06 0:42 ` Hugh Dickins @ 2014-08-06 1:04 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-08-06 1:04 UTC (permalink / raw) To: Hugh Dickins, Mel Gorman Cc: linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov Thanks Hugh, Mel. I've added both patches to my local tree and will update tomorrow with the weather. Also: On 08/05/2014 08:42 PM, Hugh Dickins wrote: > One thing I did wonder, though: at first I was reassured by the > VM_BUG_ON(!pte_present(pte)) you add to pte_mknuma(); but then thought > it would be better as VM_BUG_ON(!(val & _PAGE_PRESENT)), being stronger > - asserting that indeed we do not put NUMA hints on PROT_NONE areas. > (But I have not tested, perhaps such a VM_BUG_ON would actually fire.) I've added VM_BUG_ON(!(val & _PAGE_PRESENT)) in just as a curiosity, I'll update how that one looks as well. Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-06 1:04 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-08-06 1:04 UTC (permalink / raw) To: Hugh Dickins, Mel Gorman Cc: linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov Thanks Hugh, Mel. I've added both patches to my local tree and will update tomorrow with the weather. Also: On 08/05/2014 08:42 PM, Hugh Dickins wrote: > One thing I did wonder, though: at first I was reassured by the > VM_BUG_ON(!pte_present(pte)) you add to pte_mknuma(); but then thought > it would be better as VM_BUG_ON(!(val & _PAGE_PRESENT)), being stronger > - asserting that indeed we do not put NUMA hints on PROT_NONE areas. > (But I have not tested, perhaps such a VM_BUG_ON would actually fire.) I've added VM_BUG_ON(!(val & _PAGE_PRESENT)) in just as a curiosity, I'll update how that one looks as well. 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-08-06 1:04 ` Sasha Levin @ 2014-08-12 3:28 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-08-12 3:28 UTC (permalink / raw) To: Hugh Dickins, Mel Gorman Cc: linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 08/05/2014 09:04 PM, Sasha Levin wrote: > Thanks Hugh, Mel. I've added both patches to my local tree and will update tomorrow > with the weather. > > Also: > > On 08/05/2014 08:42 PM, Hugh Dickins wrote: >> One thing I did wonder, though: at first I was reassured by the >> VM_BUG_ON(!pte_present(pte)) you add to pte_mknuma(); but then thought >> it would be better as VM_BUG_ON(!(val & _PAGE_PRESENT)), being stronger >> - asserting that indeed we do not put NUMA hints on PROT_NONE areas. >> (But I have not tested, perhaps such a VM_BUG_ON would actually fire.) > > I've added VM_BUG_ON(!(val & _PAGE_PRESENT)) in just as a curiosity, I'll > update how that one looks as well. Sorry for the rather long delay. The patch looks fine, the issue didn't reproduce. The added VM_BUG_ON didn't trigger either, so maybe we should consider adding it in. Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-12 3:28 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-08-12 3:28 UTC (permalink / raw) To: Hugh Dickins, Mel Gorman Cc: linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 08/05/2014 09:04 PM, Sasha Levin wrote: > Thanks Hugh, Mel. I've added both patches to my local tree and will update tomorrow > with the weather. > > Also: > > On 08/05/2014 08:42 PM, Hugh Dickins wrote: >> One thing I did wonder, though: at first I was reassured by the >> VM_BUG_ON(!pte_present(pte)) you add to pte_mknuma(); but then thought >> it would be better as VM_BUG_ON(!(val & _PAGE_PRESENT)), being stronger >> - asserting that indeed we do not put NUMA hints on PROT_NONE areas. >> (But I have not tested, perhaps such a VM_BUG_ON would actually fire.) > > I've added VM_BUG_ON(!(val & _PAGE_PRESENT)) in just as a curiosity, I'll > update how that one looks as well. Sorry for the rather long delay. The patch looks fine, the issue didn't reproduce. The added VM_BUG_ON didn't trigger either, so maybe we should consider adding it in. 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] 86+ messages in thread
* [PATCH] x86,mm: fix pte_special versus pte_numa 2014-08-12 3:28 ` Sasha Levin @ 2014-08-12 10:47 ` Mel Gorman -1 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-08-12 10:47 UTC (permalink / raw) To: Andrew Morton Cc: Hugh Dickins, linux-mm, Sasha Levin, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 at mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels: where zap_pte_range() checks page->mapping to see if PageAnon(page). Those addresses fit struct pages for pfns d2001 and d2000, and in each dump a register or a stack slot showed d2001730 or d2000730: pte flags 0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has a hole between cfffffff and 100000000, which would need special access. Commit c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL pte no longer passes the pte_special() test, so zap_pte_range() goes on to try to access a non-existent struct page. Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). A hint that this was a problem was that c46a7c817e66 added pte_numa() test to vm_normal_page(), and moved its is_zero_pfn() test from slow to fast path: This was papering over a pte_special() snag when the zero page was encountered during zap. This patch reverts vm_normal_page() to how it was before, relying on pte_special(). It still appears that this patch may be incomplete: aren't there other places which need to be handling PROTNONE along with PRESENT? For example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, but on a PROT_NONE area, that would make it pte_special(). This is side-stepped by the fact that NUMA hinting faults skipped PROT_NONE VMAs and there are no grounds where a NUMA hinting fault on a PROT_NONE VMA would be interesting. Fixes: c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") Reported-and-tested-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Hugh Dickins <hughd@google.com> Signed-off-by: Mel Gorman <mgorman@suse.de> Cc: stable@vger.kernel.org [3.16] --- arch/x86/include/asm/pgtable.h | 9 +++++++-- mm/memory.c | 7 +++---- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h index 0ec0560..aa97a07 100644 --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -131,8 +131,13 @@ static inline int pte_exec(pte_t pte) static inline int pte_special(pte_t pte) { - return (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_SPECIAL)) == - (_PAGE_PRESENT|_PAGE_SPECIAL); + /* + * See CONFIG_NUMA_BALANCING pte_numa in include/asm-generic/pgtable.h. + * On x86 we have _PAGE_BIT_NUMA == _PAGE_BIT_GLOBAL+1 == + * __PAGE_BIT_SOFTW1 == _PAGE_BIT_SPECIAL. + */ + return (pte_flags(pte) & _PAGE_SPECIAL) && + (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_PROTNONE)); } static inline unsigned long pte_pfn(pte_t pte) diff --git a/mm/memory.c b/mm/memory.c index 8b44f76..0a21f3d 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -751,7 +751,7 @@ struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn = pte_pfn(pte); if (HAVE_PTE_SPECIAL) { - if (likely(!pte_special(pte) || pte_numa(pte))) + if (likely(!pte_special(pte))) goto check_pfn; if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)) return NULL; @@ -777,15 +777,14 @@ struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr, } } + if (is_zero_pfn(pfn)) + return NULL; check_pfn: if (unlikely(pfn > highest_memmap_pfn)) { print_bad_pte(vma, addr, pte, NULL); return NULL; } - if (is_zero_pfn(pfn)) - return NULL; - /* * NOTE! We still have PageReserved() pages in the page tables. * eg. VDSO mappings can cause them to exist. ^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH] x86,mm: fix pte_special versus pte_numa @ 2014-08-12 10:47 ` Mel Gorman 0 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-08-12 10:47 UTC (permalink / raw) To: Andrew Morton Cc: Hugh Dickins, linux-mm, Sasha Levin, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 at mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels: where zap_pte_range() checks page->mapping to see if PageAnon(page). Those addresses fit struct pages for pfns d2001 and d2000, and in each dump a register or a stack slot showed d2001730 or d2000730: pte flags 0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has a hole between cfffffff and 100000000, which would need special access. Commit c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL pte no longer passes the pte_special() test, so zap_pte_range() goes on to try to access a non-existent struct page. Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). A hint that this was a problem was that c46a7c817e66 added pte_numa() test to vm_normal_page(), and moved its is_zero_pfn() test from slow to fast path: This was papering over a pte_special() snag when the zero page was encountered during zap. This patch reverts vm_normal_page() to how it was before, relying on pte_special(). It still appears that this patch may be incomplete: aren't there other places which need to be handling PROTNONE along with PRESENT? For example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, but on a PROT_NONE area, that would make it pte_special(). This is side-stepped by the fact that NUMA hinting faults skipped PROT_NONE VMAs and there are no grounds where a NUMA hinting fault on a PROT_NONE VMA would be interesting. Fixes: c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") Reported-and-tested-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Hugh Dickins <hughd@google.com> Signed-off-by: Mel Gorman <mgorman@suse.de> Cc: stable@vger.kernel.org [3.16] --- arch/x86/include/asm/pgtable.h | 9 +++++++-- mm/memory.c | 7 +++---- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h index 0ec0560..aa97a07 100644 --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -131,8 +131,13 @@ static inline int pte_exec(pte_t pte) static inline int pte_special(pte_t pte) { - return (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_SPECIAL)) == - (_PAGE_PRESENT|_PAGE_SPECIAL); + /* + * See CONFIG_NUMA_BALANCING pte_numa in include/asm-generic/pgtable.h. + * On x86 we have _PAGE_BIT_NUMA == _PAGE_BIT_GLOBAL+1 == + * __PAGE_BIT_SOFTW1 == _PAGE_BIT_SPECIAL. + */ + return (pte_flags(pte) & _PAGE_SPECIAL) && + (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_PROTNONE)); } static inline unsigned long pte_pfn(pte_t pte) diff --git a/mm/memory.c b/mm/memory.c index 8b44f76..0a21f3d 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -751,7 +751,7 @@ struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn = pte_pfn(pte); if (HAVE_PTE_SPECIAL) { - if (likely(!pte_special(pte) || pte_numa(pte))) + if (likely(!pte_special(pte))) goto check_pfn; if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)) return NULL; @@ -777,15 +777,14 @@ struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr, } } + if (is_zero_pfn(pfn)) + return NULL; check_pfn: if (unlikely(pfn > highest_memmap_pfn)) { print_bad_pte(vma, addr, pte, NULL); return NULL; } - if (is_zero_pfn(pfn)) - return NULL; - /* * NOTE! We still have PageReserved() pages in the page tables. * eg. VDSO mappings can cause them to exist. -- 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] 86+ messages in thread
* [PATCH] mm: Remove misleading ARCH_USES_NUMA_PROT_NONE 2014-08-12 10:47 ` Mel Gorman @ 2014-08-12 11:08 ` Mel Gorman -1 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-08-12 11:08 UTC (permalink / raw) To: Andrew Morton Cc: Hugh Dickins, linux-mm, Sasha Levin, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented _PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting fault scanner. This was found to be conceptually confusing with a lot of implicit assumptions and it was asked that an alternative be found. Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap PTE bits and shrunk the maximum possible swap size but it did not go far enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA but the relics still exist. This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary duplication in powerpc vs the generic implementation by defining the types the core NUMA helpers expected to exist from x86 with their ppc64 equivalent. This necessitated that a PTE bit mask be created that identified the bits that distinguish present from NUMA pte entries but it is expected this will only differ between arches based on _PAGE_PROTNONE. The naming for the generic helpers was taken from x86 originally but ppc64 has types that are equivalent for the purposes of the helper so they are mapped instead of duplicating code. Signed-off-by: Mel Gorman <mgorman@suse.de> --- arch/powerpc/include/asm/pgtable.h | 57 ++++++++--------------------------- arch/powerpc/include/asm/pte-common.h | 5 +++ arch/x86/Kconfig | 1 - arch/x86/include/asm/pgtable_types.h | 14 +++++++++ include/asm-generic/pgtable.h | 27 ++++++----------- init/Kconfig | 11 ------- 6 files changed, 40 insertions(+), 75 deletions(-) diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h index d98c1ec..f60d4ea 100644 --- a/arch/powerpc/include/asm/pgtable.h +++ b/arch/powerpc/include/asm/pgtable.h @@ -38,10 +38,9 @@ static inline int pte_none(pte_t pte) { return (pte_val(pte) & ~_PTE_NONE_MASK) static inline pgprot_t pte_pgprot(pte_t pte) { return __pgprot(pte_val(pte) & PAGE_PROT_BITS); } #ifdef CONFIG_NUMA_BALANCING - static inline int pte_present(pte_t pte) { - return pte_val(pte) & (_PAGE_PRESENT | _PAGE_NUMA); + return pte_val(pte) & _PAGE_NUMA_MASK; } #define pte_present_nonuma pte_present_nonuma @@ -50,37 +49,6 @@ static inline int pte_present_nonuma(pte_t pte) return pte_val(pte) & (_PAGE_PRESENT); } -#define pte_numa pte_numa -static inline int pte_numa(pte_t pte) -{ - return (pte_val(pte) & - (_PAGE_NUMA|_PAGE_PRESENT)) == _PAGE_NUMA; -} - -#define pte_mknonnuma pte_mknonnuma -static inline pte_t pte_mknonnuma(pte_t pte) -{ - pte_val(pte) &= ~_PAGE_NUMA; - pte_val(pte) |= _PAGE_PRESENT | _PAGE_ACCESSED; - return pte; -} - -#define pte_mknuma pte_mknuma -static inline pte_t pte_mknuma(pte_t pte) -{ - /* - * We should not set _PAGE_NUMA on non present ptes. Also clear the - * present bit so that hash_page will return 1 and we collect this - * as numa fault. - */ - if (pte_present(pte)) { - pte_val(pte) |= _PAGE_NUMA; - pte_val(pte) &= ~_PAGE_PRESENT; - } else - VM_BUG_ON(1); - return pte; -} - #define ptep_set_numa ptep_set_numa static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, pte_t *ptep) @@ -92,12 +60,6 @@ static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, return; } -#define pmd_numa pmd_numa -static inline int pmd_numa(pmd_t pmd) -{ - return pte_numa(pmd_pte(pmd)); -} - #define pmdp_set_numa pmdp_set_numa static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp) @@ -109,16 +71,21 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, return; } -#define pmd_mknonnuma pmd_mknonnuma -static inline pmd_t pmd_mknonnuma(pmd_t pmd) +/* + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist + * which was inherited from x86. For the purposes of powerpc pte_basic_t and + * pmd_t are equivalent + */ +#define pteval_t pte_basic_t +#define pmdval_t pmd_t +static inline pteval_t ptenuma_flags(pte_t pte) { - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); + return pte_val(pte) & _PAGE_NUMA_MASK; } -#define pmd_mknuma pmd_mknuma -static inline pmd_t pmd_mknuma(pmd_t pmd) +static inline pmdval_t pmdnuma_flags(pmd_t pmd) { - return pte_pmd(pte_mknuma(pmd_pte(pmd))); + return pmd_val(pmd) & _PAGE_NUMA_MASK; } # else diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h index 8d1569c..e040c35 100644 --- a/arch/powerpc/include/asm/pte-common.h +++ b/arch/powerpc/include/asm/pte-common.h @@ -98,6 +98,11 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void); _PAGE_USER | _PAGE_ACCESSED | \ _PAGE_RW | _PAGE_HWWRITE | _PAGE_DIRTY | _PAGE_EXEC) +#ifdef CONFIG_NUMA_BALANCING +/* Mask of bits that distinguish present and numa ptes */ +#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PRESENT) +#endif + /* * We define 2 sets of base prot bits, one for basic pages (ie, * cacheable kernel and user pages) and one for non cacheable diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index d24887b..0a3f32b 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -28,7 +28,6 @@ config X86 select HAVE_UNSTABLE_SCHED_CLOCK select ARCH_SUPPORTS_NUMA_BALANCING if X86_64 select ARCH_SUPPORTS_INT128 if X86_64 - select ARCH_WANTS_PROT_NUMA_PROT_NONE select HAVE_IDE select HAVE_OPROFILE select HAVE_PCSPKR_PLATFORM diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h index f216963..0f9724c 100644 --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -325,6 +325,20 @@ static inline pteval_t pte_flags(pte_t pte) return native_pte_val(pte) & PTE_FLAGS_MASK; } +#ifdef CONFIG_NUMA_BALANCING +/* Set of bits that distinguishes present, prot_none and numa ptes */ +#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT) +static inline pteval_t ptenuma_flags(pte_t pte) +{ + return pte_flags(pte) & _PAGE_NUMA_MASK; +} + +static inline pmdval_t pmdnuma_flags(pmd_t pmd) +{ + return pmd_flags(pmd) & _PAGE_NUMA_MASK; +} +#endif /* CONFIG_NUMA_BALANCING */ + #define pgprot_val(x) ((x).pgprot) #define __pgprot(x) ((pgprot_t) { (x) } ) diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h index 53b2acc..281870f 100644 --- a/include/asm-generic/pgtable.h +++ b/include/asm-generic/pgtable.h @@ -660,11 +660,12 @@ static inline int pmd_trans_unstable(pmd_t *pmd) } #ifdef CONFIG_NUMA_BALANCING -#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE /* - * _PAGE_NUMA works identical to _PAGE_PROTNONE (it's actually the - * same bit too). It's set only when _PAGE_PRESET is not set and it's - * never set if _PAGE_PRESENT is set. + * _PAGE_NUMA distinguishes between an unmapped page table entry, an entry that + * is protected for PROT_NONE and a NUMA hinting fault entry. If the + * architecture defines __PAGE_PROTNONE then it should take that into account + * but those that do not can rely on the fact that the NUMA hinting scanner + * skips inaccessible VMAs. * * pte/pmd_present() returns true if pte/pmd_numa returns true. Page * fault triggers on those regions if pte/pmd_numa returns true @@ -673,16 +674,14 @@ static inline int pmd_trans_unstable(pmd_t *pmd) #ifndef pte_numa static inline int pte_numa(pte_t pte) { - return (pte_flags(pte) & - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; + return ptenuma_flags(pte) == _PAGE_NUMA; } #endif #ifndef pmd_numa static inline int pmd_numa(pmd_t pmd) { - return (pmd_flags(pmd) & - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; + return pmdnuma_flags(pmd) == _PAGE_NUMA; } #endif @@ -722,6 +721,8 @@ static inline pte_t pte_mknuma(pte_t pte) { pteval_t val = pte_val(pte); + VM_BUG_ON(!(val & _PAGE_PRESENT)); + val &= ~_PAGE_PRESENT; val |= _PAGE_NUMA; @@ -765,16 +766,6 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, } #endif #else -extern int pte_numa(pte_t pte); -extern int pmd_numa(pmd_t pmd); -extern pte_t pte_mknonnuma(pte_t pte); -extern pmd_t pmd_mknonnuma(pmd_t pmd); -extern pte_t pte_mknuma(pte_t pte); -extern pmd_t pmd_mknuma(pmd_t pmd); -extern void ptep_set_numa(struct mm_struct *mm, unsigned long addr, pte_t *ptep); -extern void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp); -#endif /* CONFIG_ARCH_USES_NUMA_PROT_NONE */ -#else static inline int pmd_numa(pmd_t pmd) { return 0; diff --git a/init/Kconfig b/init/Kconfig index 9d76b99..60fa415 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -844,17 +844,6 @@ config ARCH_SUPPORTS_INT128 config ARCH_WANT_NUMA_VARIABLE_LOCALITY bool -# -# For architectures that are willing to define _PAGE_NUMA as _PAGE_PROTNONE -config ARCH_WANTS_PROT_NUMA_PROT_NONE - bool - -config ARCH_USES_NUMA_PROT_NONE - bool - default y - depends on ARCH_WANTS_PROT_NUMA_PROT_NONE - depends on NUMA_BALANCING - config NUMA_BALANCING_DEFAULT_ENABLED bool "Automatically enable NUMA aware memory/task placement" default y ^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH] mm: Remove misleading ARCH_USES_NUMA_PROT_NONE @ 2014-08-12 11:08 ` Mel Gorman 0 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-08-12 11:08 UTC (permalink / raw) To: Andrew Morton Cc: Hugh Dickins, linux-mm, Sasha Levin, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented _PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting fault scanner. This was found to be conceptually confusing with a lot of implicit assumptions and it was asked that an alternative be found. Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap PTE bits and shrunk the maximum possible swap size but it did not go far enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA but the relics still exist. This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary duplication in powerpc vs the generic implementation by defining the types the core NUMA helpers expected to exist from x86 with their ppc64 equivalent. This necessitated that a PTE bit mask be created that identified the bits that distinguish present from NUMA pte entries but it is expected this will only differ between arches based on _PAGE_PROTNONE. The naming for the generic helpers was taken from x86 originally but ppc64 has types that are equivalent for the purposes of the helper so they are mapped instead of duplicating code. Signed-off-by: Mel Gorman <mgorman@suse.de> --- arch/powerpc/include/asm/pgtable.h | 57 ++++++++--------------------------- arch/powerpc/include/asm/pte-common.h | 5 +++ arch/x86/Kconfig | 1 - arch/x86/include/asm/pgtable_types.h | 14 +++++++++ include/asm-generic/pgtable.h | 27 ++++++----------- init/Kconfig | 11 ------- 6 files changed, 40 insertions(+), 75 deletions(-) diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h index d98c1ec..f60d4ea 100644 --- a/arch/powerpc/include/asm/pgtable.h +++ b/arch/powerpc/include/asm/pgtable.h @@ -38,10 +38,9 @@ static inline int pte_none(pte_t pte) { return (pte_val(pte) & ~_PTE_NONE_MASK) static inline pgprot_t pte_pgprot(pte_t pte) { return __pgprot(pte_val(pte) & PAGE_PROT_BITS); } #ifdef CONFIG_NUMA_BALANCING - static inline int pte_present(pte_t pte) { - return pte_val(pte) & (_PAGE_PRESENT | _PAGE_NUMA); + return pte_val(pte) & _PAGE_NUMA_MASK; } #define pte_present_nonuma pte_present_nonuma @@ -50,37 +49,6 @@ static inline int pte_present_nonuma(pte_t pte) return pte_val(pte) & (_PAGE_PRESENT); } -#define pte_numa pte_numa -static inline int pte_numa(pte_t pte) -{ - return (pte_val(pte) & - (_PAGE_NUMA|_PAGE_PRESENT)) == _PAGE_NUMA; -} - -#define pte_mknonnuma pte_mknonnuma -static inline pte_t pte_mknonnuma(pte_t pte) -{ - pte_val(pte) &= ~_PAGE_NUMA; - pte_val(pte) |= _PAGE_PRESENT | _PAGE_ACCESSED; - return pte; -} - -#define pte_mknuma pte_mknuma -static inline pte_t pte_mknuma(pte_t pte) -{ - /* - * We should not set _PAGE_NUMA on non present ptes. Also clear the - * present bit so that hash_page will return 1 and we collect this - * as numa fault. - */ - if (pte_present(pte)) { - pte_val(pte) |= _PAGE_NUMA; - pte_val(pte) &= ~_PAGE_PRESENT; - } else - VM_BUG_ON(1); - return pte; -} - #define ptep_set_numa ptep_set_numa static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, pte_t *ptep) @@ -92,12 +60,6 @@ static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, return; } -#define pmd_numa pmd_numa -static inline int pmd_numa(pmd_t pmd) -{ - return pte_numa(pmd_pte(pmd)); -} - #define pmdp_set_numa pmdp_set_numa static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp) @@ -109,16 +71,21 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, return; } -#define pmd_mknonnuma pmd_mknonnuma -static inline pmd_t pmd_mknonnuma(pmd_t pmd) +/* + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist + * which was inherited from x86. For the purposes of powerpc pte_basic_t and + * pmd_t are equivalent + */ +#define pteval_t pte_basic_t +#define pmdval_t pmd_t +static inline pteval_t ptenuma_flags(pte_t pte) { - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); + return pte_val(pte) & _PAGE_NUMA_MASK; } -#define pmd_mknuma pmd_mknuma -static inline pmd_t pmd_mknuma(pmd_t pmd) +static inline pmdval_t pmdnuma_flags(pmd_t pmd) { - return pte_pmd(pte_mknuma(pmd_pte(pmd))); + return pmd_val(pmd) & _PAGE_NUMA_MASK; } # else diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h index 8d1569c..e040c35 100644 --- a/arch/powerpc/include/asm/pte-common.h +++ b/arch/powerpc/include/asm/pte-common.h @@ -98,6 +98,11 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void); _PAGE_USER | _PAGE_ACCESSED | \ _PAGE_RW | _PAGE_HWWRITE | _PAGE_DIRTY | _PAGE_EXEC) +#ifdef CONFIG_NUMA_BALANCING +/* Mask of bits that distinguish present and numa ptes */ +#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PRESENT) +#endif + /* * We define 2 sets of base prot bits, one for basic pages (ie, * cacheable kernel and user pages) and one for non cacheable diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index d24887b..0a3f32b 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -28,7 +28,6 @@ config X86 select HAVE_UNSTABLE_SCHED_CLOCK select ARCH_SUPPORTS_NUMA_BALANCING if X86_64 select ARCH_SUPPORTS_INT128 if X86_64 - select ARCH_WANTS_PROT_NUMA_PROT_NONE select HAVE_IDE select HAVE_OPROFILE select HAVE_PCSPKR_PLATFORM diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h index f216963..0f9724c 100644 --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -325,6 +325,20 @@ static inline pteval_t pte_flags(pte_t pte) return native_pte_val(pte) & PTE_FLAGS_MASK; } +#ifdef CONFIG_NUMA_BALANCING +/* Set of bits that distinguishes present, prot_none and numa ptes */ +#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT) +static inline pteval_t ptenuma_flags(pte_t pte) +{ + return pte_flags(pte) & _PAGE_NUMA_MASK; +} + +static inline pmdval_t pmdnuma_flags(pmd_t pmd) +{ + return pmd_flags(pmd) & _PAGE_NUMA_MASK; +} +#endif /* CONFIG_NUMA_BALANCING */ + #define pgprot_val(x) ((x).pgprot) #define __pgprot(x) ((pgprot_t) { (x) } ) diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h index 53b2acc..281870f 100644 --- a/include/asm-generic/pgtable.h +++ b/include/asm-generic/pgtable.h @@ -660,11 +660,12 @@ static inline int pmd_trans_unstable(pmd_t *pmd) } #ifdef CONFIG_NUMA_BALANCING -#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE /* - * _PAGE_NUMA works identical to _PAGE_PROTNONE (it's actually the - * same bit too). It's set only when _PAGE_PRESET is not set and it's - * never set if _PAGE_PRESENT is set. + * _PAGE_NUMA distinguishes between an unmapped page table entry, an entry that + * is protected for PROT_NONE and a NUMA hinting fault entry. If the + * architecture defines __PAGE_PROTNONE then it should take that into account + * but those that do not can rely on the fact that the NUMA hinting scanner + * skips inaccessible VMAs. * * pte/pmd_present() returns true if pte/pmd_numa returns true. Page * fault triggers on those regions if pte/pmd_numa returns true @@ -673,16 +674,14 @@ static inline int pmd_trans_unstable(pmd_t *pmd) #ifndef pte_numa static inline int pte_numa(pte_t pte) { - return (pte_flags(pte) & - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; + return ptenuma_flags(pte) == _PAGE_NUMA; } #endif #ifndef pmd_numa static inline int pmd_numa(pmd_t pmd) { - return (pmd_flags(pmd) & - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; + return pmdnuma_flags(pmd) == _PAGE_NUMA; } #endif @@ -722,6 +721,8 @@ static inline pte_t pte_mknuma(pte_t pte) { pteval_t val = pte_val(pte); + VM_BUG_ON(!(val & _PAGE_PRESENT)); + val &= ~_PAGE_PRESENT; val |= _PAGE_NUMA; @@ -765,16 +766,6 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, } #endif #else -extern int pte_numa(pte_t pte); -extern int pmd_numa(pmd_t pmd); -extern pte_t pte_mknonnuma(pte_t pte); -extern pmd_t pmd_mknonnuma(pmd_t pmd); -extern pte_t pte_mknuma(pte_t pte); -extern pmd_t pmd_mknuma(pmd_t pmd); -extern void ptep_set_numa(struct mm_struct *mm, unsigned long addr, pte_t *ptep); -extern void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp); -#endif /* CONFIG_ARCH_USES_NUMA_PROT_NONE */ -#else static inline int pmd_numa(pmd_t pmd) { return 0; diff --git a/init/Kconfig b/init/Kconfig index 9d76b99..60fa415 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -844,17 +844,6 @@ config ARCH_SUPPORTS_INT128 config ARCH_WANT_NUMA_VARIABLE_LOCALITY bool -# -# For architectures that are willing to define _PAGE_NUMA as _PAGE_PROTNONE -config ARCH_WANTS_PROT_NUMA_PROT_NONE - bool - -config ARCH_USES_NUMA_PROT_NONE - bool - default y - depends on ARCH_WANTS_PROT_NUMA_PROT_NONE - depends on NUMA_BALANCING - config NUMA_BALANCING_DEFAULT_ENABLED bool "Automatically enable NUMA aware memory/task placement" default y -- 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] 86+ messages in thread
* Re: [PATCH] mm: Remove misleading ARCH_USES_NUMA_PROT_NONE 2014-08-12 11:08 ` Mel Gorman @ 2014-08-13 13:14 ` Aneesh Kumar K.V -1 siblings, 0 replies; 86+ messages in thread From: Aneesh Kumar K.V @ 2014-08-13 13:14 UTC (permalink / raw) To: Mel Gorman, Andrew Morton Cc: Hugh Dickins, linux-mm, Sasha Levin, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov Mel Gorman <mgorman@suse.de> writes: > ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented > _PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and > relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting > fault scanner. This was found to be conceptually confusing with a lot of > implicit assumptions and it was asked that an alternative be found. > > Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the > PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap > PTE bits and shrunk the maximum possible swap size but it did not go far > enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA > but the relics still exist. > > This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary > duplication in powerpc vs the generic implementation by defining the types > the core NUMA helpers expected to exist from x86 with their ppc64 equivalent. > This necessitated that a PTE bit mask be created that identified the bits > that distinguish present from NUMA pte entries but it is expected this > will only differ between arches based on _PAGE_PROTNONE. The naming for > the generic helpers was taken from x86 originally but ppc64 has types that > are equivalent for the purposes of the helper so they are mapped instead > of duplicating code. > > Signed-off-by: Mel Gorman <mgorman@suse.de> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> > --- > arch/powerpc/include/asm/pgtable.h | 57 ++++++++--------------------------- > arch/powerpc/include/asm/pte-common.h | 5 +++ > arch/x86/Kconfig | 1 - > arch/x86/include/asm/pgtable_types.h | 14 +++++++++ > include/asm-generic/pgtable.h | 27 ++++++----------- > init/Kconfig | 11 ------- > 6 files changed, 40 insertions(+), 75 deletions(-) > > diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h > index d98c1ec..f60d4ea 100644 > --- a/arch/powerpc/include/asm/pgtable.h > +++ b/arch/powerpc/include/asm/pgtable.h > @@ -38,10 +38,9 @@ static inline int pte_none(pte_t pte) { return (pte_val(pte) & ~_PTE_NONE_MASK) > static inline pgprot_t pte_pgprot(pte_t pte) { return __pgprot(pte_val(pte) & PAGE_PROT_BITS); } > > #ifdef CONFIG_NUMA_BALANCING > - > static inline int pte_present(pte_t pte) > { > - return pte_val(pte) & (_PAGE_PRESENT | _PAGE_NUMA); > + return pte_val(pte) & _PAGE_NUMA_MASK; > } > > #define pte_present_nonuma pte_present_nonuma > @@ -50,37 +49,6 @@ static inline int pte_present_nonuma(pte_t pte) > return pte_val(pte) & (_PAGE_PRESENT); > } > > -#define pte_numa pte_numa > -static inline int pte_numa(pte_t pte) > -{ > - return (pte_val(pte) & > - (_PAGE_NUMA|_PAGE_PRESENT)) == _PAGE_NUMA; > -} > - > -#define pte_mknonnuma pte_mknonnuma > -static inline pte_t pte_mknonnuma(pte_t pte) > -{ > - pte_val(pte) &= ~_PAGE_NUMA; > - pte_val(pte) |= _PAGE_PRESENT | _PAGE_ACCESSED; > - return pte; > -} > - > -#define pte_mknuma pte_mknuma > -static inline pte_t pte_mknuma(pte_t pte) > -{ > - /* > - * We should not set _PAGE_NUMA on non present ptes. Also clear the > - * present bit so that hash_page will return 1 and we collect this > - * as numa fault. > - */ > - if (pte_present(pte)) { > - pte_val(pte) |= _PAGE_NUMA; > - pte_val(pte) &= ~_PAGE_PRESENT; > - } else > - VM_BUG_ON(1); > - return pte; > -} > - > #define ptep_set_numa ptep_set_numa > static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, > pte_t *ptep) > @@ -92,12 +60,6 @@ static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, > return; > } > > -#define pmd_numa pmd_numa > -static inline int pmd_numa(pmd_t pmd) > -{ > - return pte_numa(pmd_pte(pmd)); > -} > - > #define pmdp_set_numa pmdp_set_numa > static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > pmd_t *pmdp) > @@ -109,16 +71,21 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > return; > } > > -#define pmd_mknonnuma pmd_mknonnuma > -static inline pmd_t pmd_mknonnuma(pmd_t pmd) > +/* > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist > + * which was inherited from x86. For the purposes of powerpc pte_basic_t and > + * pmd_t are equivalent > + */ > +#define pteval_t pte_basic_t > +#define pmdval_t pmd_t > +static inline pteval_t ptenuma_flags(pte_t pte) > { > - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); > + return pte_val(pte) & _PAGE_NUMA_MASK; > } > > -#define pmd_mknuma pmd_mknuma > -static inline pmd_t pmd_mknuma(pmd_t pmd) > +static inline pmdval_t pmdnuma_flags(pmd_t pmd) > { > - return pte_pmd(pte_mknuma(pmd_pte(pmd))); > + return pmd_val(pmd) & _PAGE_NUMA_MASK; > } > > # else > diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h > index 8d1569c..e040c35 100644 > --- a/arch/powerpc/include/asm/pte-common.h > +++ b/arch/powerpc/include/asm/pte-common.h > @@ -98,6 +98,11 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void); > _PAGE_USER | _PAGE_ACCESSED | \ > _PAGE_RW | _PAGE_HWWRITE | _PAGE_DIRTY | _PAGE_EXEC) > > +#ifdef CONFIG_NUMA_BALANCING > +/* Mask of bits that distinguish present and numa ptes */ > +#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PRESENT) > +#endif > + > /* > * We define 2 sets of base prot bits, one for basic pages (ie, > * cacheable kernel and user pages) and one for non cacheable > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index d24887b..0a3f32b 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -28,7 +28,6 @@ config X86 > select HAVE_UNSTABLE_SCHED_CLOCK > select ARCH_SUPPORTS_NUMA_BALANCING if X86_64 > select ARCH_SUPPORTS_INT128 if X86_64 > - select ARCH_WANTS_PROT_NUMA_PROT_NONE > select HAVE_IDE > select HAVE_OPROFILE > select HAVE_PCSPKR_PLATFORM > diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h > index f216963..0f9724c 100644 > --- a/arch/x86/include/asm/pgtable_types.h > +++ b/arch/x86/include/asm/pgtable_types.h > @@ -325,6 +325,20 @@ static inline pteval_t pte_flags(pte_t pte) > return native_pte_val(pte) & PTE_FLAGS_MASK; > } > > +#ifdef CONFIG_NUMA_BALANCING > +/* Set of bits that distinguishes present, prot_none and numa ptes */ > +#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT) > +static inline pteval_t ptenuma_flags(pte_t pte) > +{ > + return pte_flags(pte) & _PAGE_NUMA_MASK; > +} > + > +static inline pmdval_t pmdnuma_flags(pmd_t pmd) > +{ > + return pmd_flags(pmd) & _PAGE_NUMA_MASK; > +} > +#endif /* CONFIG_NUMA_BALANCING */ > + > #define pgprot_val(x) ((x).pgprot) > #define __pgprot(x) ((pgprot_t) { (x) } ) > > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h > index 53b2acc..281870f 100644 > --- a/include/asm-generic/pgtable.h > +++ b/include/asm-generic/pgtable.h > @@ -660,11 +660,12 @@ static inline int pmd_trans_unstable(pmd_t *pmd) > } > > #ifdef CONFIG_NUMA_BALANCING > -#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE > /* > - * _PAGE_NUMA works identical to _PAGE_PROTNONE (it's actually the > - * same bit too). It's set only when _PAGE_PRESET is not set and it's > - * never set if _PAGE_PRESENT is set. > + * _PAGE_NUMA distinguishes between an unmapped page table entry, an entry that > + * is protected for PROT_NONE and a NUMA hinting fault entry. If the > + * architecture defines __PAGE_PROTNONE then it should take that into account > + * but those that do not can rely on the fact that the NUMA hinting scanner > + * skips inaccessible VMAs. > * > * pte/pmd_present() returns true if pte/pmd_numa returns true. Page > * fault triggers on those regions if pte/pmd_numa returns true > @@ -673,16 +674,14 @@ static inline int pmd_trans_unstable(pmd_t *pmd) > #ifndef pte_numa > static inline int pte_numa(pte_t pte) > { > - return (pte_flags(pte) & > - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; > + return ptenuma_flags(pte) == _PAGE_NUMA; > } > #endif > > #ifndef pmd_numa > static inline int pmd_numa(pmd_t pmd) > { > - return (pmd_flags(pmd) & > - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; > + return pmdnuma_flags(pmd) == _PAGE_NUMA; > } > #endif > > @@ -722,6 +721,8 @@ static inline pte_t pte_mknuma(pte_t pte) > { > pteval_t val = pte_val(pte); > > + VM_BUG_ON(!(val & _PAGE_PRESENT)); > + > val &= ~_PAGE_PRESENT; > val |= _PAGE_NUMA; > > @@ -765,16 +766,6 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > } > #endif > #else > -extern int pte_numa(pte_t pte); > -extern int pmd_numa(pmd_t pmd); > -extern pte_t pte_mknonnuma(pte_t pte); > -extern pmd_t pmd_mknonnuma(pmd_t pmd); > -extern pte_t pte_mknuma(pte_t pte); > -extern pmd_t pmd_mknuma(pmd_t pmd); > -extern void ptep_set_numa(struct mm_struct *mm, unsigned long addr, pte_t *ptep); > -extern void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp); > -#endif /* CONFIG_ARCH_USES_NUMA_PROT_NONE */ > -#else > static inline int pmd_numa(pmd_t pmd) > { > return 0; > diff --git a/init/Kconfig b/init/Kconfig > index 9d76b99..60fa415 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -844,17 +844,6 @@ config ARCH_SUPPORTS_INT128 > config ARCH_WANT_NUMA_VARIABLE_LOCALITY > bool > > -# > -# For architectures that are willing to define _PAGE_NUMA as _PAGE_PROTNONE > -config ARCH_WANTS_PROT_NUMA_PROT_NONE > - bool > - > -config ARCH_USES_NUMA_PROT_NONE > - bool > - default y > - depends on ARCH_WANTS_PROT_NUMA_PROT_NONE > - depends on NUMA_BALANCING > - > config NUMA_BALANCING_DEFAULT_ENABLED > bool "Automatically enable NUMA aware memory/task placement" > default y > > -- > 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] 86+ messages in thread
* Re: [PATCH] mm: Remove misleading ARCH_USES_NUMA_PROT_NONE @ 2014-08-13 13:14 ` Aneesh Kumar K.V 0 siblings, 0 replies; 86+ messages in thread From: Aneesh Kumar K.V @ 2014-08-13 13:14 UTC (permalink / raw) To: Mel Gorman, Andrew Morton Cc: Hugh Dickins, linux-mm, Sasha Levin, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov Mel Gorman <mgorman@suse.de> writes: > ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented > _PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and > relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting > fault scanner. This was found to be conceptually confusing with a lot of > implicit assumptions and it was asked that an alternative be found. > > Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the > PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap > PTE bits and shrunk the maximum possible swap size but it did not go far > enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA > but the relics still exist. > > This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary > duplication in powerpc vs the generic implementation by defining the types > the core NUMA helpers expected to exist from x86 with their ppc64 equivalent. > This necessitated that a PTE bit mask be created that identified the bits > that distinguish present from NUMA pte entries but it is expected this > will only differ between arches based on _PAGE_PROTNONE. The naming for > the generic helpers was taken from x86 originally but ppc64 has types that > are equivalent for the purposes of the helper so they are mapped instead > of duplicating code. > > Signed-off-by: Mel Gorman <mgorman@suse.de> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> > --- > arch/powerpc/include/asm/pgtable.h | 57 ++++++++--------------------------- > arch/powerpc/include/asm/pte-common.h | 5 +++ > arch/x86/Kconfig | 1 - > arch/x86/include/asm/pgtable_types.h | 14 +++++++++ > include/asm-generic/pgtable.h | 27 ++++++----------- > init/Kconfig | 11 ------- > 6 files changed, 40 insertions(+), 75 deletions(-) > > diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h > index d98c1ec..f60d4ea 100644 > --- a/arch/powerpc/include/asm/pgtable.h > +++ b/arch/powerpc/include/asm/pgtable.h > @@ -38,10 +38,9 @@ static inline int pte_none(pte_t pte) { return (pte_val(pte) & ~_PTE_NONE_MASK) > static inline pgprot_t pte_pgprot(pte_t pte) { return __pgprot(pte_val(pte) & PAGE_PROT_BITS); } > > #ifdef CONFIG_NUMA_BALANCING > - > static inline int pte_present(pte_t pte) > { > - return pte_val(pte) & (_PAGE_PRESENT | _PAGE_NUMA); > + return pte_val(pte) & _PAGE_NUMA_MASK; > } > > #define pte_present_nonuma pte_present_nonuma > @@ -50,37 +49,6 @@ static inline int pte_present_nonuma(pte_t pte) > return pte_val(pte) & (_PAGE_PRESENT); > } > > -#define pte_numa pte_numa > -static inline int pte_numa(pte_t pte) > -{ > - return (pte_val(pte) & > - (_PAGE_NUMA|_PAGE_PRESENT)) == _PAGE_NUMA; > -} > - > -#define pte_mknonnuma pte_mknonnuma > -static inline pte_t pte_mknonnuma(pte_t pte) > -{ > - pte_val(pte) &= ~_PAGE_NUMA; > - pte_val(pte) |= _PAGE_PRESENT | _PAGE_ACCESSED; > - return pte; > -} > - > -#define pte_mknuma pte_mknuma > -static inline pte_t pte_mknuma(pte_t pte) > -{ > - /* > - * We should not set _PAGE_NUMA on non present ptes. Also clear the > - * present bit so that hash_page will return 1 and we collect this > - * as numa fault. > - */ > - if (pte_present(pte)) { > - pte_val(pte) |= _PAGE_NUMA; > - pte_val(pte) &= ~_PAGE_PRESENT; > - } else > - VM_BUG_ON(1); > - return pte; > -} > - > #define ptep_set_numa ptep_set_numa > static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, > pte_t *ptep) > @@ -92,12 +60,6 @@ static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, > return; > } > > -#define pmd_numa pmd_numa > -static inline int pmd_numa(pmd_t pmd) > -{ > - return pte_numa(pmd_pte(pmd)); > -} > - > #define pmdp_set_numa pmdp_set_numa > static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > pmd_t *pmdp) > @@ -109,16 +71,21 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > return; > } > > -#define pmd_mknonnuma pmd_mknonnuma > -static inline pmd_t pmd_mknonnuma(pmd_t pmd) > +/* > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist > + * which was inherited from x86. For the purposes of powerpc pte_basic_t and > + * pmd_t are equivalent > + */ > +#define pteval_t pte_basic_t > +#define pmdval_t pmd_t > +static inline pteval_t ptenuma_flags(pte_t pte) > { > - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); > + return pte_val(pte) & _PAGE_NUMA_MASK; > } > > -#define pmd_mknuma pmd_mknuma > -static inline pmd_t pmd_mknuma(pmd_t pmd) > +static inline pmdval_t pmdnuma_flags(pmd_t pmd) > { > - return pte_pmd(pte_mknuma(pmd_pte(pmd))); > + return pmd_val(pmd) & _PAGE_NUMA_MASK; > } > > # else > diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h > index 8d1569c..e040c35 100644 > --- a/arch/powerpc/include/asm/pte-common.h > +++ b/arch/powerpc/include/asm/pte-common.h > @@ -98,6 +98,11 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void); > _PAGE_USER | _PAGE_ACCESSED | \ > _PAGE_RW | _PAGE_HWWRITE | _PAGE_DIRTY | _PAGE_EXEC) > > +#ifdef CONFIG_NUMA_BALANCING > +/* Mask of bits that distinguish present and numa ptes */ > +#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PRESENT) > +#endif > + > /* > * We define 2 sets of base prot bits, one for basic pages (ie, > * cacheable kernel and user pages) and one for non cacheable > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index d24887b..0a3f32b 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -28,7 +28,6 @@ config X86 > select HAVE_UNSTABLE_SCHED_CLOCK > select ARCH_SUPPORTS_NUMA_BALANCING if X86_64 > select ARCH_SUPPORTS_INT128 if X86_64 > - select ARCH_WANTS_PROT_NUMA_PROT_NONE > select HAVE_IDE > select HAVE_OPROFILE > select HAVE_PCSPKR_PLATFORM > diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h > index f216963..0f9724c 100644 > --- a/arch/x86/include/asm/pgtable_types.h > +++ b/arch/x86/include/asm/pgtable_types.h > @@ -325,6 +325,20 @@ static inline pteval_t pte_flags(pte_t pte) > return native_pte_val(pte) & PTE_FLAGS_MASK; > } > > +#ifdef CONFIG_NUMA_BALANCING > +/* Set of bits that distinguishes present, prot_none and numa ptes */ > +#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT) > +static inline pteval_t ptenuma_flags(pte_t pte) > +{ > + return pte_flags(pte) & _PAGE_NUMA_MASK; > +} > + > +static inline pmdval_t pmdnuma_flags(pmd_t pmd) > +{ > + return pmd_flags(pmd) & _PAGE_NUMA_MASK; > +} > +#endif /* CONFIG_NUMA_BALANCING */ > + > #define pgprot_val(x) ((x).pgprot) > #define __pgprot(x) ((pgprot_t) { (x) } ) > > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h > index 53b2acc..281870f 100644 > --- a/include/asm-generic/pgtable.h > +++ b/include/asm-generic/pgtable.h > @@ -660,11 +660,12 @@ static inline int pmd_trans_unstable(pmd_t *pmd) > } > > #ifdef CONFIG_NUMA_BALANCING > -#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE > /* > - * _PAGE_NUMA works identical to _PAGE_PROTNONE (it's actually the > - * same bit too). It's set only when _PAGE_PRESET is not set and it's > - * never set if _PAGE_PRESENT is set. > + * _PAGE_NUMA distinguishes between an unmapped page table entry, an entry that > + * is protected for PROT_NONE and a NUMA hinting fault entry. If the > + * architecture defines __PAGE_PROTNONE then it should take that into account > + * but those that do not can rely on the fact that the NUMA hinting scanner > + * skips inaccessible VMAs. > * > * pte/pmd_present() returns true if pte/pmd_numa returns true. Page > * fault triggers on those regions if pte/pmd_numa returns true > @@ -673,16 +674,14 @@ static inline int pmd_trans_unstable(pmd_t *pmd) > #ifndef pte_numa > static inline int pte_numa(pte_t pte) > { > - return (pte_flags(pte) & > - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; > + return ptenuma_flags(pte) == _PAGE_NUMA; > } > #endif > > #ifndef pmd_numa > static inline int pmd_numa(pmd_t pmd) > { > - return (pmd_flags(pmd) & > - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; > + return pmdnuma_flags(pmd) == _PAGE_NUMA; > } > #endif > > @@ -722,6 +721,8 @@ static inline pte_t pte_mknuma(pte_t pte) > { > pteval_t val = pte_val(pte); > > + VM_BUG_ON(!(val & _PAGE_PRESENT)); > + > val &= ~_PAGE_PRESENT; > val |= _PAGE_NUMA; > > @@ -765,16 +766,6 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > } > #endif > #else > -extern int pte_numa(pte_t pte); > -extern int pmd_numa(pmd_t pmd); > -extern pte_t pte_mknonnuma(pte_t pte); > -extern pmd_t pmd_mknonnuma(pmd_t pmd); > -extern pte_t pte_mknuma(pte_t pte); > -extern pmd_t pmd_mknuma(pmd_t pmd); > -extern void ptep_set_numa(struct mm_struct *mm, unsigned long addr, pte_t *ptep); > -extern void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp); > -#endif /* CONFIG_ARCH_USES_NUMA_PROT_NONE */ > -#else > static inline int pmd_numa(pmd_t pmd) > { > return 0; > diff --git a/init/Kconfig b/init/Kconfig > index 9d76b99..60fa415 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -844,17 +844,6 @@ config ARCH_SUPPORTS_INT128 > config ARCH_WANT_NUMA_VARIABLE_LOCALITY > bool > > -# > -# For architectures that are willing to define _PAGE_NUMA as _PAGE_PROTNONE > -config ARCH_WANTS_PROT_NUMA_PROT_NONE > - bool > - > -config ARCH_USES_NUMA_PROT_NONE > - bool > - default y > - depends on ARCH_WANTS_PROT_NUMA_PROT_NONE > - depends on NUMA_BALANCING > - > config NUMA_BALANCING_DEFAULT_ENABLED > bool "Automatically enable NUMA aware memory/task placement" > default y > > -- > 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-08-12 3:28 ` Sasha Levin @ 2014-08-27 3:16 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-08-27 3:16 UTC (permalink / raw) To: Hugh Dickins, Mel Gorman Cc: linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 08/11/2014 11:28 PM, Sasha Levin wrote: > On 08/05/2014 09:04 PM, Sasha Levin wrote: >> > Thanks Hugh, Mel. I've added both patches to my local tree and will update tomorrow >> > with the weather. >> > >> > Also: >> > >> > On 08/05/2014 08:42 PM, Hugh Dickins wrote: >>> >> One thing I did wonder, though: at first I was reassured by the >>> >> VM_BUG_ON(!pte_present(pte)) you add to pte_mknuma(); but then thought >>> >> it would be better as VM_BUG_ON(!(val & _PAGE_PRESENT)), being stronger >>> >> - asserting that indeed we do not put NUMA hints on PROT_NONE areas. >>> >> (But I have not tested, perhaps such a VM_BUG_ON would actually fire.) >> > >> > I've added VM_BUG_ON(!(val & _PAGE_PRESENT)) in just as a curiosity, I'll >> > update how that one looks as well. > Sorry for the rather long delay. > > The patch looks fine, the issue didn't reproduce. > > The added VM_BUG_ON didn't trigger either, so maybe we should consider adding > it in. It took a while, but I've managed to hit that VM_BUG_ON: [ 707.975456] kernel BUG at include/asm-generic/pgtable.h:724! [ 707.977147] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 707.978974] Dumping ftrace buffer: [ 707.980110] (ftrace buffer empty) [ 707.981221] Modules linked in: [ 707.982312] CPU: 18 PID: 9488 Comm: trinity-c538 Not tainted 3.17.0-rc2-next-20140826-sasha-00031-gc48c9ac-dirty #1079 [ 707.982801] task: ffff880165e28000 ti: ffff880165e30000 task.ti: ffff880165e30000 [ 707.982801] RIP: 0010:[<ffffffffb42e3dda>] [<ffffffffb42e3dda>] change_protection_range+0x94a/0x970 [ 707.982801] RSP: 0018:ffff880165e33d98 EFLAGS: 00010246 [ 707.982801] RAX: 000000009d340902 RBX: ffff880511204a08 RCX: 0000000000000100 [ 707.982801] RDX: 000000009d340902 RSI: 0000000041741000 RDI: 000000009d340902 [ 707.982801] RBP: ffff880165e33e88 R08: ffff880708a23c00 R09: 0000000000b52000 [ 707.982801] R10: 0000000000001e01 R11: 0000000000000008 R12: 0000000041751000 [ 707.982801] R13: 00000000000000f7 R14: 000000009d340902 R15: 0000000041741000 [ 707.982801] FS: 00007f358a9aa700(0000) GS:ffff88071c600000(0000) knlGS:0000000000000000 [ 707.982801] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 707.982801] CR2: 00007f3586b69490 CR3: 0000000165d88000 CR4: 00000000000006a0 [ 707.982801] Stack: [ 707.982801] ffff8804db88d058 0000000000000000 ffff88070fb17cf0 0000000000000000 [ 707.982801] ffff880165d88000 0000000000000000 ffff8801686a5000 000000004163e000 [ 707.982801] ffff8801686a5000 0000000000000001 0000000000000025 0000000041750fff [ 707.982801] Call Trace: [ 707.982801] [<ffffffffb42e3e14>] change_protection+0x14/0x30 [ 707.982801] [<ffffffffb42fda3b>] change_prot_numa+0x1b/0x40 [ 707.982801] [<ffffffffb41ad766>] task_numa_work+0x1f6/0x330 [ 707.982801] [<ffffffffb41937c4>] task_work_run+0xc4/0xf0 [ 707.982801] [<ffffffffb40712e7>] do_notify_resume+0x97/0xb0 [ 707.982801] [<ffffffffb74fd6ea>] int_signal+0x12/0x17 [ 707.982801] Code: e8 2c 84 21 03 e9 72 ff ff ff 0f 1f 80 00 00 00 00 0f 0b 48 8b 7d a8 4c 89 f2 4c 89 fe e8 9f 7b 03 00 e9 47 f9 ff ff 0f 0b 0f 0b <0f> 0b 0f 0b 48 8b b5 70 ff ff ff 4c 89 ea 48 89 c7 e8 10 d5 01 [ 707.982801] RIP [<ffffffffb42e3dda>] change_protection_range+0x94a/0x970 [ 707.982801] RSP <ffff880165e33d98> Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-27 3:16 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-08-27 3:16 UTC (permalink / raw) To: Hugh Dickins, Mel Gorman Cc: linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 08/11/2014 11:28 PM, Sasha Levin wrote: > On 08/05/2014 09:04 PM, Sasha Levin wrote: >> > Thanks Hugh, Mel. I've added both patches to my local tree and will update tomorrow >> > with the weather. >> > >> > Also: >> > >> > On 08/05/2014 08:42 PM, Hugh Dickins wrote: >>> >> One thing I did wonder, though: at first I was reassured by the >>> >> VM_BUG_ON(!pte_present(pte)) you add to pte_mknuma(); but then thought >>> >> it would be better as VM_BUG_ON(!(val & _PAGE_PRESENT)), being stronger >>> >> - asserting that indeed we do not put NUMA hints on PROT_NONE areas. >>> >> (But I have not tested, perhaps such a VM_BUG_ON would actually fire.) >> > >> > I've added VM_BUG_ON(!(val & _PAGE_PRESENT)) in just as a curiosity, I'll >> > update how that one looks as well. > Sorry for the rather long delay. > > The patch looks fine, the issue didn't reproduce. > > The added VM_BUG_ON didn't trigger either, so maybe we should consider adding > it in. It took a while, but I've managed to hit that VM_BUG_ON: [ 707.975456] kernel BUG at include/asm-generic/pgtable.h:724! [ 707.977147] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 707.978974] Dumping ftrace buffer: [ 707.980110] (ftrace buffer empty) [ 707.981221] Modules linked in: [ 707.982312] CPU: 18 PID: 9488 Comm: trinity-c538 Not tainted 3.17.0-rc2-next-20140826-sasha-00031-gc48c9ac-dirty #1079 [ 707.982801] task: ffff880165e28000 ti: ffff880165e30000 task.ti: ffff880165e30000 [ 707.982801] RIP: 0010:[<ffffffffb42e3dda>] [<ffffffffb42e3dda>] change_protection_range+0x94a/0x970 [ 707.982801] RSP: 0018:ffff880165e33d98 EFLAGS: 00010246 [ 707.982801] RAX: 000000009d340902 RBX: ffff880511204a08 RCX: 0000000000000100 [ 707.982801] RDX: 000000009d340902 RSI: 0000000041741000 RDI: 000000009d340902 [ 707.982801] RBP: ffff880165e33e88 R08: ffff880708a23c00 R09: 0000000000b52000 [ 707.982801] R10: 0000000000001e01 R11: 0000000000000008 R12: 0000000041751000 [ 707.982801] R13: 00000000000000f7 R14: 000000009d340902 R15: 0000000041741000 [ 707.982801] FS: 00007f358a9aa700(0000) GS:ffff88071c600000(0000) knlGS:0000000000000000 [ 707.982801] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 707.982801] CR2: 00007f3586b69490 CR3: 0000000165d88000 CR4: 00000000000006a0 [ 707.982801] Stack: [ 707.982801] ffff8804db88d058 0000000000000000 ffff88070fb17cf0 0000000000000000 [ 707.982801] ffff880165d88000 0000000000000000 ffff8801686a5000 000000004163e000 [ 707.982801] ffff8801686a5000 0000000000000001 0000000000000025 0000000041750fff [ 707.982801] Call Trace: [ 707.982801] [<ffffffffb42e3e14>] change_protection+0x14/0x30 [ 707.982801] [<ffffffffb42fda3b>] change_prot_numa+0x1b/0x40 [ 707.982801] [<ffffffffb41ad766>] task_numa_work+0x1f6/0x330 [ 707.982801] [<ffffffffb41937c4>] task_work_run+0xc4/0xf0 [ 707.982801] [<ffffffffb40712e7>] do_notify_resume+0x97/0xb0 [ 707.982801] [<ffffffffb74fd6ea>] int_signal+0x12/0x17 [ 707.982801] Code: e8 2c 84 21 03 e9 72 ff ff ff 0f 1f 80 00 00 00 00 0f 0b 48 8b 7d a8 4c 89 f2 4c 89 fe e8 9f 7b 03 00 e9 47 f9 ff ff 0f 0b 0f 0b <0f> 0b 0f 0b 48 8b b5 70 ff ff ff 4c 89 ea 48 89 c7 e8 10 d5 01 [ 707.982801] RIP [<ffffffffb42e3dda>] change_protection_range+0x94a/0x970 [ 707.982801] RSP <ffff880165e33d98> 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-08-27 3:16 ` Sasha Levin @ 2014-08-27 15:26 ` Mel Gorman -1 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-08-27 15:26 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Tue, Aug 26, 2014 at 11:16:47PM -0400, Sasha Levin wrote: > On 08/11/2014 11:28 PM, Sasha Levin wrote: > > On 08/05/2014 09:04 PM, Sasha Levin wrote: > >> > Thanks Hugh, Mel. I've added both patches to my local tree and will update tomorrow > >> > with the weather. > >> > > >> > Also: > >> > > >> > On 08/05/2014 08:42 PM, Hugh Dickins wrote: > >>> >> One thing I did wonder, though: at first I was reassured by the > >>> >> VM_BUG_ON(!pte_present(pte)) you add to pte_mknuma(); but then thought > >>> >> it would be better as VM_BUG_ON(!(val & _PAGE_PRESENT)), being stronger > >>> >> - asserting that indeed we do not put NUMA hints on PROT_NONE areas. > >>> >> (But I have not tested, perhaps such a VM_BUG_ON would actually fire.) > >> > > >> > I've added VM_BUG_ON(!(val & _PAGE_PRESENT)) in just as a curiosity, I'll > >> > update how that one looks as well. > > Sorry for the rather long delay. > > > > The patch looks fine, the issue didn't reproduce. > > > > The added VM_BUG_ON didn't trigger either, so maybe we should consider adding > > it in. > > It took a while, but I've managed to hit that VM_BUG_ON: > > [ 707.975456] kernel BUG at include/asm-generic/pgtable.h:724! > [ 707.977147] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 707.978974] Dumping ftrace buffer: > [ 707.980110] (ftrace buffer empty) > [ 707.981221] Modules linked in: > [ 707.982312] CPU: 18 PID: 9488 Comm: trinity-c538 Not tainted 3.17.0-rc2-next-20140826-sasha-00031-gc48c9ac-dirty #1079 > [ 707.982801] task: ffff880165e28000 ti: ffff880165e30000 task.ti: ffff880165e30000 > [ 707.982801] RIP: 0010:[<ffffffffb42e3dda>] [<ffffffffb42e3dda>] change_protection_range+0x94a/0x970 > [ 707.982801] RSP: 0018:ffff880165e33d98 EFLAGS: 00010246 > [ 707.982801] RAX: 000000009d340902 RBX: ffff880511204a08 RCX: 0000000000000100 > [ 707.982801] RDX: 000000009d340902 RSI: 0000000041741000 RDI: 000000009d340902 > [ 707.982801] RBP: ffff880165e33e88 R08: ffff880708a23c00 R09: 0000000000b52000 > [ 707.982801] R10: 0000000000001e01 R11: 0000000000000008 R12: 0000000041751000 > [ 707.982801] R13: 00000000000000f7 R14: 000000009d340902 R15: 0000000041741000 > [ 707.982801] FS: 00007f358a9aa700(0000) GS:ffff88071c600000(0000) knlGS:0000000000000000 > [ 707.982801] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 707.982801] CR2: 00007f3586b69490 CR3: 0000000165d88000 CR4: 00000000000006a0 > [ 707.982801] Stack: > [ 707.982801] ffff8804db88d058 0000000000000000 ffff88070fb17cf0 0000000000000000 > [ 707.982801] ffff880165d88000 0000000000000000 ffff8801686a5000 000000004163e000 > [ 707.982801] ffff8801686a5000 0000000000000001 0000000000000025 0000000041750fff > [ 707.982801] Call Trace: > [ 707.982801] [<ffffffffb42e3e14>] change_protection+0x14/0x30 > [ 707.982801] [<ffffffffb42fda3b>] change_prot_numa+0x1b/0x40 > [ 707.982801] [<ffffffffb41ad766>] task_numa_work+0x1f6/0x330 > [ 707.982801] [<ffffffffb41937c4>] task_work_run+0xc4/0xf0 > [ 707.982801] [<ffffffffb40712e7>] do_notify_resume+0x97/0xb0 > [ 707.982801] [<ffffffffb74fd6ea>] int_signal+0x12/0x17 > [ 707.982801] Code: e8 2c 84 21 03 e9 72 ff ff ff 0f 1f 80 00 00 00 00 0f 0b 48 8b 7d a8 4c 89 f2 4c 89 fe e8 9f 7b 03 00 e9 47 f9 ff ff 0f 0b 0f 0b <0f> 0b 0f 0b 48 8b b5 70 ff ff ff 4c 89 ea 48 89 c7 e8 10 d5 01 > [ 707.982801] RIP [<ffffffffb42e3dda>] change_protection_range+0x94a/0x970 > [ 707.982801] RSP <ffff880165e33d98> > The tests to reach here are pte_present any of _PAGE_PRESENT | _PAGE_PROTNONE | _PAGE_NUMA pte_numa only _PAGE_NUMA out of _PAGE_PRESENT | _PAGE_PROTNONE | _PAGE_NUMA VM_BUG_ON not set _PAGE_PRESENT To trigger the bug the PTE bits must then be _PAGE_PROTNONE | _PAGE_NUMA. The NUMA PTE scanner is skipping PROT_NONE VMAs so it should be "impossible" for it to be set there. The mmap_sem is held for read during scans so the protections should not be altering underneath us and the PTL is held against parallel faults. That leaves setting prot_none leaveing _PAGE_NUMA behind. Potentially that's an issue due to /* Set of bits not changed in pte_modify */ #define _PAGE_CHG_MASK (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT | \ _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY | \ _PAGE_SOFT_DIRTY | _PAGE_NUMA) The _PAGE_NUMA bit is not cleared as removing it potentially leaves the PTE in an unexpected state due to a "present" PTE marked for NUMA hinting fault becoming non-present. Instead there is this check in change_pte_range() to move PTEs to a known state before changing protections if (pte_numa(ptent)) ptent = pte_mknonnuma(ptent); ptent = pte_modify(ptent, newprot); So right now, I'm not seeing what path gets us to this inconsistent state. Sasha, how long does it typically take to trigger this? Are you using any particular switches for trinity that would trigger the bug faster? This untested patch might help pinpoint the source of the corruption early though it's x86 only diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h index 281870f..ffea570 100644 --- a/include/asm-generic/pgtable.h +++ b/include/asm-generic/pgtable.h @@ -723,6 +723,9 @@ static inline pte_t pte_mknuma(pte_t pte) VM_BUG_ON(!(val & _PAGE_PRESENT)); + /* debugging only, specific to x86 */ + VM_BUG_ON(val & _PAGE_PROTNONE); + val &= ~_PAGE_PRESENT; val |= _PAGE_NUMA; ^ permalink raw reply related [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-27 15:26 ` Mel Gorman 0 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-08-27 15:26 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Tue, Aug 26, 2014 at 11:16:47PM -0400, Sasha Levin wrote: > On 08/11/2014 11:28 PM, Sasha Levin wrote: > > On 08/05/2014 09:04 PM, Sasha Levin wrote: > >> > Thanks Hugh, Mel. I've added both patches to my local tree and will update tomorrow > >> > with the weather. > >> > > >> > Also: > >> > > >> > On 08/05/2014 08:42 PM, Hugh Dickins wrote: > >>> >> One thing I did wonder, though: at first I was reassured by the > >>> >> VM_BUG_ON(!pte_present(pte)) you add to pte_mknuma(); but then thought > >>> >> it would be better as VM_BUG_ON(!(val & _PAGE_PRESENT)), being stronger > >>> >> - asserting that indeed we do not put NUMA hints on PROT_NONE areas. > >>> >> (But I have not tested, perhaps such a VM_BUG_ON would actually fire.) > >> > > >> > I've added VM_BUG_ON(!(val & _PAGE_PRESENT)) in just as a curiosity, I'll > >> > update how that one looks as well. > > Sorry for the rather long delay. > > > > The patch looks fine, the issue didn't reproduce. > > > > The added VM_BUG_ON didn't trigger either, so maybe we should consider adding > > it in. > > It took a while, but I've managed to hit that VM_BUG_ON: > > [ 707.975456] kernel BUG at include/asm-generic/pgtable.h:724! > [ 707.977147] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 707.978974] Dumping ftrace buffer: > [ 707.980110] (ftrace buffer empty) > [ 707.981221] Modules linked in: > [ 707.982312] CPU: 18 PID: 9488 Comm: trinity-c538 Not tainted 3.17.0-rc2-next-20140826-sasha-00031-gc48c9ac-dirty #1079 > [ 707.982801] task: ffff880165e28000 ti: ffff880165e30000 task.ti: ffff880165e30000 > [ 707.982801] RIP: 0010:[<ffffffffb42e3dda>] [<ffffffffb42e3dda>] change_protection_range+0x94a/0x970 > [ 707.982801] RSP: 0018:ffff880165e33d98 EFLAGS: 00010246 > [ 707.982801] RAX: 000000009d340902 RBX: ffff880511204a08 RCX: 0000000000000100 > [ 707.982801] RDX: 000000009d340902 RSI: 0000000041741000 RDI: 000000009d340902 > [ 707.982801] RBP: ffff880165e33e88 R08: ffff880708a23c00 R09: 0000000000b52000 > [ 707.982801] R10: 0000000000001e01 R11: 0000000000000008 R12: 0000000041751000 > [ 707.982801] R13: 00000000000000f7 R14: 000000009d340902 R15: 0000000041741000 > [ 707.982801] FS: 00007f358a9aa700(0000) GS:ffff88071c600000(0000) knlGS:0000000000000000 > [ 707.982801] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 707.982801] CR2: 00007f3586b69490 CR3: 0000000165d88000 CR4: 00000000000006a0 > [ 707.982801] Stack: > [ 707.982801] ffff8804db88d058 0000000000000000 ffff88070fb17cf0 0000000000000000 > [ 707.982801] ffff880165d88000 0000000000000000 ffff8801686a5000 000000004163e000 > [ 707.982801] ffff8801686a5000 0000000000000001 0000000000000025 0000000041750fff > [ 707.982801] Call Trace: > [ 707.982801] [<ffffffffb42e3e14>] change_protection+0x14/0x30 > [ 707.982801] [<ffffffffb42fda3b>] change_prot_numa+0x1b/0x40 > [ 707.982801] [<ffffffffb41ad766>] task_numa_work+0x1f6/0x330 > [ 707.982801] [<ffffffffb41937c4>] task_work_run+0xc4/0xf0 > [ 707.982801] [<ffffffffb40712e7>] do_notify_resume+0x97/0xb0 > [ 707.982801] [<ffffffffb74fd6ea>] int_signal+0x12/0x17 > [ 707.982801] Code: e8 2c 84 21 03 e9 72 ff ff ff 0f 1f 80 00 00 00 00 0f 0b 48 8b 7d a8 4c 89 f2 4c 89 fe e8 9f 7b 03 00 e9 47 f9 ff ff 0f 0b 0f 0b <0f> 0b 0f 0b 48 8b b5 70 ff ff ff 4c 89 ea 48 89 c7 e8 10 d5 01 > [ 707.982801] RIP [<ffffffffb42e3dda>] change_protection_range+0x94a/0x970 > [ 707.982801] RSP <ffff880165e33d98> > The tests to reach here are pte_present any of _PAGE_PRESENT | _PAGE_PROTNONE | _PAGE_NUMA pte_numa only _PAGE_NUMA out of _PAGE_PRESENT | _PAGE_PROTNONE | _PAGE_NUMA VM_BUG_ON not set _PAGE_PRESENT To trigger the bug the PTE bits must then be _PAGE_PROTNONE | _PAGE_NUMA. The NUMA PTE scanner is skipping PROT_NONE VMAs so it should be "impossible" for it to be set there. The mmap_sem is held for read during scans so the protections should not be altering underneath us and the PTL is held against parallel faults. That leaves setting prot_none leaveing _PAGE_NUMA behind. Potentially that's an issue due to /* Set of bits not changed in pte_modify */ #define _PAGE_CHG_MASK (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT | \ _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY | \ _PAGE_SOFT_DIRTY | _PAGE_NUMA) The _PAGE_NUMA bit is not cleared as removing it potentially leaves the PTE in an unexpected state due to a "present" PTE marked for NUMA hinting fault becoming non-present. Instead there is this check in change_pte_range() to move PTEs to a known state before changing protections if (pte_numa(ptent)) ptent = pte_mknonnuma(ptent); ptent = pte_modify(ptent, newprot); So right now, I'm not seeing what path gets us to this inconsistent state. Sasha, how long does it typically take to trigger this? Are you using any particular switches for trinity that would trigger the bug faster? This untested patch might help pinpoint the source of the corruption early though it's x86 only diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h index 281870f..ffea570 100644 --- a/include/asm-generic/pgtable.h +++ b/include/asm-generic/pgtable.h @@ -723,6 +723,9 @@ static inline pte_t pte_mknuma(pte_t pte) VM_BUG_ON(!(val & _PAGE_PRESENT)); + /* debugging only, specific to x86 */ + VM_BUG_ON(val & _PAGE_PROTNONE); + val &= ~_PAGE_PRESENT; val |= _PAGE_NUMA; -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-08-27 15:26 ` Mel Gorman @ 2014-08-27 18:21 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-08-27 18:21 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 08/27/2014 11:26 AM, Mel Gorman wrote: > Sasha, how long does it typically take to trigger this? Are you > using any particular switches for trinity that would trigger the bug > faster? It took couple of weeks (I've been running with it since the beginning of August). I don't have any special trinity options, just the default fuzzing. Do you think that focusing on any of the mm syscalls would increase the odds of hitting it? There's always the chance that this is a fluke due to corruption somewhere else. I'll keep running it with the new debug patch and if it won't reproduce any time soon we can probably safely assume that. Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-27 18:21 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-08-27 18:21 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 08/27/2014 11:26 AM, Mel Gorman wrote: > Sasha, how long does it typically take to trigger this? Are you > using any particular switches for trinity that would trigger the bug > faster? It took couple of weeks (I've been running with it since the beginning of August). I don't have any special trinity options, just the default fuzzing. Do you think that focusing on any of the mm syscalls would increase the odds of hitting it? There's always the chance that this is a fluke due to corruption somewhere else. I'll keep running it with the new debug patch and if it won't reproduce any time soon we can probably safely assume 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-08-27 15:26 ` Mel Gorman @ 2014-08-30 1:23 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-08-30 1:23 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 08/27/2014 11:26 AM, Mel Gorman wrote: > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h > index 281870f..ffea570 100644 > --- a/include/asm-generic/pgtable.h > +++ b/include/asm-generic/pgtable.h > @@ -723,6 +723,9 @@ static inline pte_t pte_mknuma(pte_t pte) > > VM_BUG_ON(!(val & _PAGE_PRESENT)); > > + /* debugging only, specific to x86 */ > + VM_BUG_ON(val & _PAGE_PROTNONE); > + > val &= ~_PAGE_PRESENT; > val |= _PAGE_NUMA; Triggered again, the first VM_BUG_ON got hit, the second one never did. Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-30 1:23 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-08-30 1:23 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 08/27/2014 11:26 AM, Mel Gorman wrote: > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h > index 281870f..ffea570 100644 > --- a/include/asm-generic/pgtable.h > +++ b/include/asm-generic/pgtable.h > @@ -723,6 +723,9 @@ static inline pte_t pte_mknuma(pte_t pte) > > VM_BUG_ON(!(val & _PAGE_PRESENT)); > > + /* debugging only, specific to x86 */ > + VM_BUG_ON(val & _PAGE_PROTNONE); > + > val &= ~_PAGE_PRESENT; > val |= _PAGE_NUMA; Triggered again, the first VM_BUG_ON got hit, the second one never did. 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-08-30 1:23 ` Sasha Levin @ 2014-09-04 9:04 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-04 9:04 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 08/29/2014 09:23 PM, Sasha Levin wrote: > On 08/27/2014 11:26 AM, Mel Gorman wrote: >> > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h >> > index 281870f..ffea570 100644 >> > --- a/include/asm-generic/pgtable.h >> > +++ b/include/asm-generic/pgtable.h >> > @@ -723,6 +723,9 @@ static inline pte_t pte_mknuma(pte_t pte) >> > >> > VM_BUG_ON(!(val & _PAGE_PRESENT)); >> > >> > + /* debugging only, specific to x86 */ >> > + VM_BUG_ON(val & _PAGE_PROTNONE); >> > + >> > val &= ~_PAGE_PRESENT; >> > val |= _PAGE_NUMA; > Triggered again, the first VM_BUG_ON got hit, the second one never did. Okay, this bug has reproduced quite a few times since then that I no longer suspect it's random memory corruption. I'd be happy to try out more debug patches if you have any leads. Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-04 9:04 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-04 9:04 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 08/29/2014 09:23 PM, Sasha Levin wrote: > On 08/27/2014 11:26 AM, Mel Gorman wrote: >> > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h >> > index 281870f..ffea570 100644 >> > --- a/include/asm-generic/pgtable.h >> > +++ b/include/asm-generic/pgtable.h >> > @@ -723,6 +723,9 @@ static inline pte_t pte_mknuma(pte_t pte) >> > >> > VM_BUG_ON(!(val & _PAGE_PRESENT)); >> > >> > + /* debugging only, specific to x86 */ >> > + VM_BUG_ON(val & _PAGE_PROTNONE); >> > + >> > val &= ~_PAGE_PRESENT; >> > val |= _PAGE_NUMA; > Triggered again, the first VM_BUG_ON got hit, the second one never did. Okay, this bug has reproduced quite a few times since then that I no longer suspect it's random memory corruption. I'd be happy to try out more debug patches if you have any leads. 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-04 9:04 ` Sasha Levin @ 2014-09-08 17:18 ` Mel Gorman -1 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-09-08 17:18 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Thu, Sep 04, 2014 at 05:04:37AM -0400, Sasha Levin wrote: > On 08/29/2014 09:23 PM, Sasha Levin wrote: > > On 08/27/2014 11:26 AM, Mel Gorman wrote: > >> > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h > >> > index 281870f..ffea570 100644 > >> > --- a/include/asm-generic/pgtable.h > >> > +++ b/include/asm-generic/pgtable.h > >> > @@ -723,6 +723,9 @@ static inline pte_t pte_mknuma(pte_t pte) > >> > > >> > VM_BUG_ON(!(val & _PAGE_PRESENT)); > >> > > >> > + /* debugging only, specific to x86 */ > >> > + VM_BUG_ON(val & _PAGE_PROTNONE); > >> > + > >> > val &= ~_PAGE_PRESENT; > >> > val |= _PAGE_NUMA; > > Triggered again, the first VM_BUG_ON got hit, the second one never did. > > Okay, this bug has reproduced quite a few times since then that I no longer > suspect it's random memory corruption. I'd be happy to try out more debug > patches if you have any leads. > The fact the second one doesn't trigger makes me think that this is not related to how the helpers are called and is instead relating to timing. I tried reproducing this but got nothing after 3 hours. How long does it typically take to reproduce in a given run? You mentioned that it takes a few weeks to hit but maybe the frequency has changed since. I tried todays linux-next kernel but it didn't even boot so next-20140826 to match your original report but got nothing. Can you also send me the config you used in case that's a factor. I had one hunch that this may somehow be related to a collision between pagetable teardown during exit and the scanner but I could not find a way that could actually happen. During teardown there should be only one user of the mm and it can't race with itself. A worse possibility is that somehow the lock is getting corrupted but that's also a tough sell considering that the locks should be allocated from a dedicated cache. I guess I could try breaking that to allocate one page per lock so DEBUG_PAGEALLOC triggers but I'm not very optimistic. -- Mel Gorman SUSE Labs ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-08 17:18 ` Mel Gorman 0 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-09-08 17:18 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Thu, Sep 04, 2014 at 05:04:37AM -0400, Sasha Levin wrote: > On 08/29/2014 09:23 PM, Sasha Levin wrote: > > On 08/27/2014 11:26 AM, Mel Gorman wrote: > >> > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h > >> > index 281870f..ffea570 100644 > >> > --- a/include/asm-generic/pgtable.h > >> > +++ b/include/asm-generic/pgtable.h > >> > @@ -723,6 +723,9 @@ static inline pte_t pte_mknuma(pte_t pte) > >> > > >> > VM_BUG_ON(!(val & _PAGE_PRESENT)); > >> > > >> > + /* debugging only, specific to x86 */ > >> > + VM_BUG_ON(val & _PAGE_PROTNONE); > >> > + > >> > val &= ~_PAGE_PRESENT; > >> > val |= _PAGE_NUMA; > > Triggered again, the first VM_BUG_ON got hit, the second one never did. > > Okay, this bug has reproduced quite a few times since then that I no longer > suspect it's random memory corruption. I'd be happy to try out more debug > patches if you have any leads. > The fact the second one doesn't trigger makes me think that this is not related to how the helpers are called and is instead relating to timing. I tried reproducing this but got nothing after 3 hours. How long does it typically take to reproduce in a given run? You mentioned that it takes a few weeks to hit but maybe the frequency has changed since. I tried todays linux-next kernel but it didn't even boot so next-20140826 to match your original report but got nothing. Can you also send me the config you used in case that's a factor. I had one hunch that this may somehow be related to a collision between pagetable teardown during exit and the scanner but I could not find a way that could actually happen. During teardown there should be only one user of the mm and it can't race with itself. A worse possibility is that somehow the lock is getting corrupted but that's also a tough sell considering that the locks should be allocated from a dedicated cache. I guess I could try breaking that to allocate one page per lock so DEBUG_PAGEALLOC triggers but I'm not very optimistic. -- Mel Gorman SUSE Labs -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-08 17:18 ` Mel Gorman (?) @ 2014-09-08 17:23 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-08 17:23 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov [-- Attachment #1: Type: text/plain, Size: 2195 bytes --] On 09/08/2014 01:18 PM, Mel Gorman wrote: > On Thu, Sep 04, 2014 at 05:04:37AM -0400, Sasha Levin wrote: >> On 08/29/2014 09:23 PM, Sasha Levin wrote: >>> On 08/27/2014 11:26 AM, Mel Gorman wrote: >>>>> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h >>>>> index 281870f..ffea570 100644 >>>>> --- a/include/asm-generic/pgtable.h >>>>> +++ b/include/asm-generic/pgtable.h >>>>> @@ -723,6 +723,9 @@ static inline pte_t pte_mknuma(pte_t pte) >>>>> >>>>> VM_BUG_ON(!(val & _PAGE_PRESENT)); >>>>> >>>>> + /* debugging only, specific to x86 */ >>>>> + VM_BUG_ON(val & _PAGE_PROTNONE); >>>>> + >>>>> val &= ~_PAGE_PRESENT; >>>>> val |= _PAGE_NUMA; >>> Triggered again, the first VM_BUG_ON got hit, the second one never did. >> >> Okay, this bug has reproduced quite a few times since then that I no longer >> suspect it's random memory corruption. I'd be happy to try out more debug >> patches if you have any leads. >> > > The fact the second one doesn't trigger makes me think that this is not > related to how the helpers are called and is instead relating to timing. > I tried reproducing this but got nothing after 3 hours. How long does it > typically take to reproduce in a given run? You mentioned that it takes a > few weeks to hit but maybe the frequency has changed since. I tried todays > linux-next kernel but it didn't even boot so next-20140826 to match your > original report but got nothing. Can you also send me the config you used > in case that's a factor. The frequency seems to have changed, I can trigger this 5-10 times a day now. Config is attached. Thanks, Sasha > I had one hunch that this may somehow be related to a collision between > pagetable teardown during exit and the scanner but I could not find a > way that could actually happen. During teardown there should be only one > user of the mm and it can't race with itself. > > A worse possibility is that somehow the lock is getting corrupted but > that's also a tough sell considering that the locks should be allocated > from a dedicated cache. I guess I could try breaking that to allocate > one page per lock so DEBUG_PAGEALLOC triggers but I'm not very > optimistic. [-- Attachment #2: config-sasha --] [-- Type: text/plain, Size: 161990 bytes --] # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.17.0-rc4 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_HAVE_INTEL_TXT=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="-sasha" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set # CONFIG_NO_HZ_IDLE is not set CONFIG_NO_HZ_FULL=y CONFIG_NO_HZ_FULL_ALL=y CONFIG_NO_HZ_FULL_SYSIDLE=y CONFIG_NO_HZ_FULL_SYSIDLE_SMALL=8 CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_TREE_PREEMPT_RCU=y CONFIG_PREEMPT_RCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_CONTEXT_TRACKING=y CONFIG_RCU_USER_QS=y CONFIG_CONTEXT_TRACKING_FORCE=y CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_RCU_FANOUT_EXACT=y CONFIG_RCU_FAST_NO_HZ=y CONFIG_TREE_RCU_TRACE=y CONFIG_RCU_BOOST=y CONFIG_RCU_BOOST_PRIO=10 CONFIG_RCU_BOOST_DELAY=500 CONFIG_RCU_NOCB_CPU=y CONFIG_RCU_NOCB_CPU_NONE=y # CONFIG_RCU_NOCB_CPU_ZERO is not set # CONFIG_RCU_NOCB_CPU_ALL is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=21 CONFIG_LOG_CPU_MAX_BUF_SHIFT=21 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y CONFIG_NUMA_BALANCING=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y CONFIG_MEMCG_SWAP_ENABLED=y CONFIG_MEMCG_KMEM=y CONFIG_CGROUP_HUGETLB=y CONFIG_CGROUP_PERF=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y CONFIG_RT_GROUP_SCHED=y CONFIG_BLK_CGROUP=y CONFIG_DEBUG_BLK_CGROUP=y CONFIG_CHECKPOINT_RESTORE=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_SCHED_AUTOGROUP=y CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_EXPERT=y CONFIG_UID16=y CONFIG_SGETMASK_SYSCALL=y CONFIG_SYSFS_SYSCALL=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_PCI_QUIRKS=y CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y CONFIG_DEBUG_PERF_USE_VMALLOC=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_SLUB_CPU_PARTIAL=y CONFIG_SYSTEM_TRUSTED_KEYRING=y CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_OPROFILE=y CONFIG_OPROFILE_EVENT_MULTIPLEX=y CONFIG_HAVE_OPROFILE=y CONFIG_OPROFILE_NMI_TIMER=y CONFIG_KPROBES=y CONFIG_JUMP_LABEL=y CONFIG_KPROBES_ON_FTRACE=y CONFIG_UPROBES=y # CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_ARCH_USE_BUILTIN_BSWAP=y CONFIG_KRETPROBES=y CONFIG_USER_RETURN_NOTIFIER=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_OPTPROBES=y CONFIG_HAVE_KPROBES_ON_FTRACE=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_HAVE_DMA_CONTIGUOUS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_CLK=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y CONFIG_HAVE_USER_RETURN_NOTIFIER=y CONFIG_HAVE_PERF_EVENTS_NMI=y CONFIG_HAVE_PERF_REGS=y CONFIG_HAVE_PERF_USER_STACK_DUMP=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y CONFIG_HAVE_CMPXCHG_LOCAL=y CONFIG_HAVE_CMPXCHG_DOUBLE=y CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y CONFIG_HAVE_ARCH_SECCOMP_FILTER=y CONFIG_SECCOMP_FILTER=y CONFIG_HAVE_CC_STACKPROTECTOR=y CONFIG_CC_STACKPROTECTOR=y # CONFIG_CC_STACKPROTECTOR_NONE is not set CONFIG_CC_STACKPROTECTOR_REGULAR=y # CONFIG_CC_STACKPROTECTOR_STRONG is not set CONFIG_HAVE_CONTEXT_TRACKING=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y CONFIG_HAVE_ARCH_SOFT_DIRTY=y CONFIG_MODULES_USE_ELF_RELA=y CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y CONFIG_OLD_SIGSUSPEND3=y CONFIG_COMPAT_OLD_SIGACTION=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_MODULE_SIG=y # CONFIG_MODULE_SIG_FORCE is not set CONFIG_MODULE_SIG_ALL=y CONFIG_MODULE_SIG_SHA1=y # CONFIG_MODULE_SIG_SHA224 is not set # CONFIG_MODULE_SIG_SHA256 is not set # CONFIG_MODULE_SIG_SHA384 is not set # CONFIG_MODULE_SIG_SHA512 is not set CONFIG_MODULE_SIG_HASH="sha1" CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_BLK_DEV_BSG=y CONFIG_BLK_DEV_BSGLIB=y CONFIG_BLK_DEV_INTEGRITY=y CONFIG_BLK_DEV_THROTTLING=y CONFIG_BLK_CMDLINE_PARSER=y # # Partition Types # CONFIG_PARTITION_ADVANCED=y CONFIG_ACORN_PARTITION=y CONFIG_ACORN_PARTITION_CUMANA=y CONFIG_ACORN_PARTITION_EESOX=y CONFIG_ACORN_PARTITION_ICS=y CONFIG_ACORN_PARTITION_ADFS=y CONFIG_ACORN_PARTITION_POWERTEC=y CONFIG_ACORN_PARTITION_RISCIX=y CONFIG_AIX_PARTITION=y CONFIG_OSF_PARTITION=y CONFIG_AMIGA_PARTITION=y CONFIG_ATARI_PARTITION=y CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y CONFIG_LDM_PARTITION=y CONFIG_LDM_DEBUG=y CONFIG_SGI_PARTITION=y CONFIG_ULTRIX_PARTITION=y CONFIG_SUN_PARTITION=y CONFIG_KARMA_PARTITION=y CONFIG_EFI_PARTITION=y CONFIG_SYSV68_PARTITION=y CONFIG_CMDLINE_PARTITION=y CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_PREEMPT_NOTIFIERS=y CONFIG_PADATA=y CONFIG_ASN1=y CONFIG_UNINLINE_SPIN_UNLOCK=y CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y CONFIG_RWSEM_SPIN_ON_OWNER=y CONFIG_ARCH_USE_QUEUE_RWLOCK=y CONFIG_QUEUE_RWLOCK=y CONFIG_FREEZER=y # # Processor type and features # CONFIG_ZONE_DMA=y CONFIG_SMP=y CONFIG_X86_X2APIC=y CONFIG_X86_MPPARSE=y CONFIG_X86_EXTENDED_PLATFORM=y CONFIG_X86_NUMACHIP=y CONFIG_X86_VSMP=y CONFIG_X86_UV=y # CONFIG_X86_GOLDFISH is not set CONFIG_X86_INTEL_LPSS=y CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_HYPERVISOR_GUEST=y CONFIG_PARAVIRT=y CONFIG_PARAVIRT_DEBUG=y CONFIG_PARAVIRT_SPINLOCKS=y CONFIG_XEN=y CONFIG_XEN_DOM0=y CONFIG_XEN_PVHVM=y CONFIG_XEN_MAX_DOMAIN_MEMORY=500 CONFIG_XEN_SAVE_RESTORE=y CONFIG_XEN_DEBUG_FS=y CONFIG_XEN_PVH=y CONFIG_KVM_GUEST=y CONFIG_KVM_DEBUG_FS=y CONFIG_PARAVIRT_TIME_ACCOUNTING=y CONFIG_PARAVIRT_CLOCK=y CONFIG_NO_BOOTMEM=y CONFIG_MEMTEST=y # CONFIG_MK8 is not set # CONFIG_MPSC is not set CONFIG_MCORE2=y # CONFIG_MATOM is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_INTERNODE_CACHE_SHIFT=12 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_P6_NOP=y CONFIG_X86_TSC=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=64 CONFIG_X86_DEBUGCTLMSR=y CONFIG_PROCESSOR_SELECT=y CONFIG_CPU_SUP_INTEL=y CONFIG_CPU_SUP_AMD=y CONFIG_CPU_SUP_CENTAUR=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_DMI=y CONFIG_GART_IOMMU=y CONFIG_CALGARY_IOMMU=y CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y CONFIG_MAXSMP=y CONFIG_NR_CPUS=8192 CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_COUNT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y CONFIG_X86_MCE_AMD=y CONFIG_X86_MCE_THRESHOLD=y CONFIG_X86_MCE_INJECT=y CONFIG_X86_THERMAL_VECTOR=y CONFIG_X86_16BIT=y CONFIG_X86_ESPFIX64=y CONFIG_I8K=y CONFIG_MICROCODE=y CONFIG_MICROCODE_INTEL=y CONFIG_MICROCODE_AMD=y CONFIG_MICROCODE_OLD_INTERFACE=y # CONFIG_MICROCODE_INTEL_EARLY is not set # CONFIG_MICROCODE_AMD_EARLY is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_DIRECT_GBPAGES=y CONFIG_NUMA=y CONFIG_AMD_NUMA=y CONFIG_X86_64_ACPI_NUMA=y CONFIG_NODES_SPAN_OTHER_NODES=y CONFIG_NUMA_EMU=y CONFIG_NODES_SHIFT=10 CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_MEMORY_PROBE=y CONFIG_ARCH_PROC_KCORE_TEXT=y CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000 CONFIG_SELECT_MEMORY_MODEL=y CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_NEED_MULTIPLE_NODES=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y CONFIG_SPARSEMEM_VMEMMAP=y CONFIG_HAVE_MEMBLOCK=y CONFIG_HAVE_MEMBLOCK_NODE_MAP=y CONFIG_ARCH_DISCARD_MEMBLOCK=y CONFIG_MEMORY_ISOLATION=y CONFIG_MOVABLE_NODE=y CONFIG_HAVE_BOOTMEM_INFO_NODE=y CONFIG_MEMORY_HOTPLUG=y CONFIG_MEMORY_HOTPLUG_SPARSE=y CONFIG_MEMORY_HOTREMOVE=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y CONFIG_MEMORY_BALLOON=y CONFIG_BALLOON_COMPACTION=y CONFIG_COMPACTION=y CONFIG_MIGRATION=y CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_NEED_BOUNCE_POOL=y CONFIG_VIRT_TO_BUS=y CONFIG_MMU_NOTIFIER=y CONFIG_KSM=y CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y CONFIG_MEMORY_FAILURE=y CONFIG_HWPOISON_INJECT=y CONFIG_TRANSPARENT_HUGEPAGE=y CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y # CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set CONFIG_CLEANCACHE=y CONFIG_FRONTSWAP=y CONFIG_CMA=y CONFIG_CMA_DEBUG=y CONFIG_CMA_AREAS=7 CONFIG_MEM_SOFT_DIRTY=y CONFIG_ZSWAP=y CONFIG_ZPOOL=y CONFIG_ZBUD=y CONFIG_ZSMALLOC=y CONFIG_PGTABLE_MAPPING=y CONFIG_GENERIC_EARLY_IOREMAP=y CONFIG_X86_CHECK_BIOS_CORRUPTION=y CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y CONFIG_X86_RESERVE_LOW=64 CONFIG_MTRR=y CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 CONFIG_X86_PAT=y CONFIG_ARCH_USES_PG_UNCACHED=y CONFIG_ARCH_RANDOM=y CONFIG_X86_SMAP=y CONFIG_EFI=y # CONFIG_EFI_STUB is not set CONFIG_SECCOMP=y CONFIG_HZ_100=y # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set # CONFIG_HZ_10000 is not set CONFIG_HZ=100 CONFIG_SCHED_HRTICK=y CONFIG_KEXEC=y CONFIG_KEXEC_FILE=y CONFIG_KEXEC_VERIFY_SIG=y CONFIG_KEXEC_BZIMAGE_VERIFY_SIG=y CONFIG_CRASH_DUMP=y CONFIG_PHYSICAL_START=0x1000000 CONFIG_RELOCATABLE=y CONFIG_RANDOMIZE_BASE=y CONFIG_RANDOMIZE_BASE_MAX_OFFSET=0x40000000 CONFIG_X86_NEED_RELOCS=y CONFIG_PHYSICAL_ALIGN=0x1000000 CONFIG_HOTPLUG_CPU=y CONFIG_BOOTPARAM_HOTPLUG_CPU0=y CONFIG_DEBUG_HOTPLUG_CPU0=y CONFIG_COMPAT_VDSO=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="" # CONFIG_CMDLINE_OVERRIDE is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y CONFIG_USE_PERCPU_NUMA_NODE_ID=y # # Power management and ACPI options # CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HIBERNATE_CALLBACKS=y # CONFIG_HIBERNATION is not set CONFIG_PM_SLEEP=y CONFIG_PM_SLEEP_SMP=y CONFIG_PM_AUTOSLEEP=y CONFIG_PM_WAKELOCKS=y CONFIG_PM_WAKELOCKS_LIMIT=0 CONFIG_PM_WAKELOCKS_GC=y CONFIG_PM_RUNTIME=y CONFIG_PM=y CONFIG_PM_DEBUG=y CONFIG_PM_ADVANCED_DEBUG=y CONFIG_PM_TEST_SUSPEND=y CONFIG_PM_SLEEP_DEBUG=y CONFIG_DPM_WATCHDOG=y CONFIG_DPM_WATCHDOG_TIMEOUT=12 CONFIG_PM_TRACE=y CONFIG_PM_TRACE_RTC=y CONFIG_PM_CLK=y CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y CONFIG_ACPI=y CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS_POWER=y CONFIG_ACPI_EC_DEBUGFS=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_FAN=y CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_PROCESSOR_AGGREGATOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_NUMA=y # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_DEBUG=y CONFIG_ACPI_PCI_SLOT=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=y CONFIG_ACPI_HOTPLUG_MEMORY=y CONFIG_ACPI_SBS=y CONFIG_ACPI_HED=y CONFIG_ACPI_CUSTOM_METHOD=y CONFIG_ACPI_BGRT=y CONFIG_ACPI_REDUCED_HARDWARE_ONLY=y CONFIG_HAVE_ACPI_APEI=y CONFIG_HAVE_ACPI_APEI_NMI=y CONFIG_ACPI_APEI=y CONFIG_ACPI_APEI_GHES=y CONFIG_ACPI_APEI_PCIEAER=y CONFIG_ACPI_APEI_MEMORY_FAILURE=y CONFIG_ACPI_APEI_EINJ=y CONFIG_ACPI_APEI_ERST_DEBUG=y CONFIG_ACPI_EXTLOG=y CONFIG_SFI=y # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_GOV_COMMON=y CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y # # x86 CPU frequency scaling drivers # CONFIG_X86_INTEL_PSTATE=y CONFIG_X86_PCC_CPUFREQ=y CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_ACPI_CPUFREQ_CPB=y CONFIG_X86_POWERNOW_K8=y CONFIG_X86_AMD_FREQ_SENSITIVITY=y CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_P4_CLOCKMOD=y # # shared options # CONFIG_X86_SPEEDSTEP_LIB=y # # CPU Idle # CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y # CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set CONFIG_INTEL_IDLE=y # # Memory power savings # CONFIG_I7300_IDLE_IOAT_CHANNEL=y CONFIG_I7300_IDLE=y # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_XEN=y CONFIG_PCI_DOMAINS=y CONFIG_PCI_CNB20LE_QUIRK=y CONFIG_PCIEPORTBUS=y CONFIG_HOTPLUG_PCI_PCIE=y CONFIG_PCIEAER=y CONFIG_PCIE_ECRC=y CONFIG_PCIEAER_INJECT=y CONFIG_PCIEASPM=y CONFIG_PCIEASPM_DEBUG=y CONFIG_PCIEASPM_DEFAULT=y # CONFIG_PCIEASPM_POWERSAVE is not set # CONFIG_PCIEASPM_PERFORMANCE is not set CONFIG_PCIE_PME=y CONFIG_PCI_MSI=y CONFIG_PCI_DEBUG=y CONFIG_PCI_REALLOC_ENABLE_AUTO=y CONFIG_PCI_STUB=y CONFIG_XEN_PCIDEV_FRONTEND=y CONFIG_HT_IRQ=y CONFIG_PCI_ATS=y CONFIG_PCI_IOV=y CONFIG_PCI_PRI=y CONFIG_PCI_PASID=y CONFIG_PCI_IOAPIC=y CONFIG_PCI_LABEL=y # # PCI host controller drivers # CONFIG_ISA_DMA_API=y CONFIG_AMD_NB=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=y CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y CONFIG_PD6729=y CONFIG_I82092=y CONFIG_PCCARD_NONSTATIC=y CONFIG_HOTPLUG_PCI=y CONFIG_HOTPLUG_PCI_ACPI=y CONFIG_HOTPLUG_PCI_ACPI_IBM=y CONFIG_HOTPLUG_PCI_CPCI=y CONFIG_HOTPLUG_PCI_CPCI_ZT5550=y CONFIG_HOTPLUG_PCI_CPCI_GENERIC=y CONFIG_HOTPLUG_PCI_SHPC=y CONFIG_RAPIDIO=y CONFIG_RAPIDIO_TSI721=y CONFIG_RAPIDIO_DISC_TIMEOUT=30 CONFIG_RAPIDIO_ENABLE_RX_TX_PORTS=y CONFIG_RAPIDIO_DMA_ENGINE=y CONFIG_RAPIDIO_DEBUG=y CONFIG_RAPIDIO_ENUM_BASIC=y # # RapidIO Switch drivers # CONFIG_RAPIDIO_TSI57X=y CONFIG_RAPIDIO_CPS_XX=y CONFIG_RAPIDIO_TSI568=y CONFIG_RAPIDIO_CPS_GEN2=y CONFIG_X86_SYSFB=y # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y CONFIG_BINFMT_SCRIPT=y # CONFIG_HAVE_AOUT is not set CONFIG_BINFMT_MISC=y CONFIG_COREDUMP=y CONFIG_IA32_EMULATION=y CONFIG_IA32_AOUT=y CONFIG_X86_X32=y CONFIG_COMPAT=y CONFIG_COMPAT_FOR_U64_ALIGNMENT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_KEYS_COMPAT=y CONFIG_X86_DEV_DMA_OPS=y CONFIG_IOSF_MBI=m CONFIG_PMC_ATOM=y CONFIG_NET=y CONFIG_COMPAT_NETLINK_MESSAGES=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_DIAG=y CONFIG_UNIX=y CONFIG_UNIX_DIAG=y CONFIG_XFRM=y CONFIG_XFRM_ALGO=y CONFIG_XFRM_USER=y CONFIG_XFRM_SUB_POLICY=y CONFIG_XFRM_MIGRATE=y CONFIG_XFRM_STATISTICS=y CONFIG_XFRM_IPCOMP=y CONFIG_NET_KEY=y CONFIG_NET_KEY_MIGRATE=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_FIB_TRIE_STATS=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_ROUTE_CLASSID=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y CONFIG_NET_IPIP=y CONFIG_NET_IPGRE_DEMUX=y CONFIG_NET_IP_TUNNEL=y CONFIG_NET_IPGRE=y CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_MROUTE_MULTIPLE_TABLES=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y CONFIG_SYN_COOKIES=y CONFIG_NET_IPVTI=y CONFIG_NET_UDP_TUNNEL=y CONFIG_INET_AH=y CONFIG_INET_ESP=y CONFIG_INET_IPCOMP=y CONFIG_INET_XFRM_TUNNEL=y CONFIG_INET_TUNNEL=y CONFIG_INET_XFRM_MODE_TRANSPORT=y CONFIG_INET_XFRM_MODE_TUNNEL=y CONFIG_INET_XFRM_MODE_BEET=y CONFIG_INET_LRO=y CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y CONFIG_INET_UDP_DIAG=y CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=y CONFIG_TCP_CONG_CUBIC=y CONFIG_TCP_CONG_WESTWOOD=y CONFIG_TCP_CONG_HTCP=y CONFIG_TCP_CONG_HSTCP=y CONFIG_TCP_CONG_HYBLA=y CONFIG_TCP_CONG_VEGAS=y CONFIG_TCP_CONG_SCALABLE=y CONFIG_TCP_CONG_LP=y CONFIG_TCP_CONG_VENO=y CONFIG_TCP_CONG_YEAH=y CONFIG_TCP_CONG_ILLINOIS=y # CONFIG_DEFAULT_BIC is not set CONFIG_DEFAULT_CUBIC=y # CONFIG_DEFAULT_HTCP is not set # CONFIG_DEFAULT_HYBLA is not set # CONFIG_DEFAULT_VEGAS is not set # CONFIG_DEFAULT_VENO is not set # CONFIG_DEFAULT_WESTWOOD is not set # CONFIG_DEFAULT_RENO is not set CONFIG_DEFAULT_TCP_CONG="cubic" CONFIG_TCP_MD5SIG=y CONFIG_IPV6=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y CONFIG_IPV6_OPTIMISTIC_DAD=y CONFIG_INET6_AH=y CONFIG_INET6_ESP=y CONFIG_INET6_IPCOMP=y CONFIG_IPV6_MIP6=y CONFIG_INET6_XFRM_TUNNEL=y CONFIG_INET6_TUNNEL=y CONFIG_INET6_XFRM_MODE_TRANSPORT=y CONFIG_INET6_XFRM_MODE_TUNNEL=y CONFIG_INET6_XFRM_MODE_BEET=y CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=y CONFIG_IPV6_VTI=y CONFIG_IPV6_SIT=y CONFIG_IPV6_SIT_6RD=y CONFIG_IPV6_NDISC_NODETYPE=y CONFIG_IPV6_TUNNEL=y CONFIG_IPV6_GRE=y CONFIG_IPV6_MULTIPLE_TABLES=y CONFIG_IPV6_SUBTREES=y CONFIG_IPV6_MROUTE=y CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y CONFIG_IPV6_PIMSM_V2=y CONFIG_NETLABEL=y CONFIG_NETWORK_SECMARK=y CONFIG_NET_PTP_CLASSIFY=y CONFIG_NETWORK_PHY_TIMESTAMPING=y CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y CONFIG_NETFILTER_ADVANCED=y CONFIG_BRIDGE_NETFILTER=y # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_NETLINK_ACCT=y CONFIG_NETFILTER_NETLINK_QUEUE=y CONFIG_NETFILTER_NETLINK_LOG=y CONFIG_NF_CONNTRACK=y CONFIG_NF_LOG_COMMON=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_ZONES=y CONFIG_NF_CONNTRACK_PROCFS=y CONFIG_NF_CONNTRACK_EVENTS=y CONFIG_NF_CONNTRACK_TIMEOUT=y CONFIG_NF_CONNTRACK_TIMESTAMP=y CONFIG_NF_CONNTRACK_LABELS=y CONFIG_NF_CT_PROTO_DCCP=y CONFIG_NF_CT_PROTO_GRE=y CONFIG_NF_CT_PROTO_SCTP=y CONFIG_NF_CT_PROTO_UDPLITE=y CONFIG_NF_CONNTRACK_AMANDA=y CONFIG_NF_CONNTRACK_FTP=y CONFIG_NF_CONNTRACK_H323=y CONFIG_NF_CONNTRACK_IRC=y CONFIG_NF_CONNTRACK_BROADCAST=y CONFIG_NF_CONNTRACK_NETBIOS_NS=y CONFIG_NF_CONNTRACK_SNMP=y CONFIG_NF_CONNTRACK_PPTP=y CONFIG_NF_CONNTRACK_SANE=y CONFIG_NF_CONNTRACK_SIP=y CONFIG_NF_CONNTRACK_TFTP=y CONFIG_NF_CT_NETLINK=y CONFIG_NF_CT_NETLINK_TIMEOUT=y CONFIG_NF_CT_NETLINK_HELPER=y CONFIG_NETFILTER_NETLINK_QUEUE_CT=y CONFIG_NF_NAT=y CONFIG_NF_NAT_NEEDED=y CONFIG_NF_NAT_PROTO_DCCP=y CONFIG_NF_NAT_PROTO_UDPLITE=y CONFIG_NF_NAT_PROTO_SCTP=y CONFIG_NF_NAT_AMANDA=y CONFIG_NF_NAT_FTP=y CONFIG_NF_NAT_IRC=y CONFIG_NF_NAT_SIP=y CONFIG_NF_NAT_TFTP=y CONFIG_NETFILTER_SYNPROXY=y CONFIG_NF_TABLES=y CONFIG_NF_TABLES_INET=y CONFIG_NFT_EXTHDR=y CONFIG_NFT_META=y CONFIG_NFT_CT=y CONFIG_NFT_RBTREE=y CONFIG_NFT_HASH=y CONFIG_NFT_COUNTER=y CONFIG_NFT_LOG=y CONFIG_NFT_LIMIT=y CONFIG_NFT_NAT=y CONFIG_NFT_QUEUE=y CONFIG_NFT_REJECT=y CONFIG_NFT_REJECT_INET=y CONFIG_NFT_COMPAT=y CONFIG_NETFILTER_XTABLES=y # # Xtables combined modules # CONFIG_NETFILTER_XT_MARK=y CONFIG_NETFILTER_XT_CONNMARK=y CONFIG_NETFILTER_XT_SET=y # # Xtables targets # CONFIG_NETFILTER_XT_TARGET_AUDIT=y CONFIG_NETFILTER_XT_TARGET_CHECKSUM=y CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y CONFIG_NETFILTER_XT_TARGET_CONNMARK=y CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y CONFIG_NETFILTER_XT_TARGET_CT=y CONFIG_NETFILTER_XT_TARGET_DSCP=y CONFIG_NETFILTER_XT_TARGET_HL=y CONFIG_NETFILTER_XT_TARGET_HMARK=y CONFIG_NETFILTER_XT_TARGET_IDLETIMER=y CONFIG_NETFILTER_XT_TARGET_LED=y CONFIG_NETFILTER_XT_TARGET_LOG=y CONFIG_NETFILTER_XT_TARGET_MARK=y CONFIG_NETFILTER_XT_NAT=y CONFIG_NETFILTER_XT_TARGET_NETMAP=y CONFIG_NETFILTER_XT_TARGET_NFLOG=y CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y CONFIG_NETFILTER_XT_TARGET_NOTRACK=y CONFIG_NETFILTER_XT_TARGET_RATEEST=y CONFIG_NETFILTER_XT_TARGET_REDIRECT=y CONFIG_NETFILTER_XT_TARGET_TEE=y CONFIG_NETFILTER_XT_TARGET_TPROXY=y CONFIG_NETFILTER_XT_TARGET_TRACE=y CONFIG_NETFILTER_XT_TARGET_SECMARK=y CONFIG_NETFILTER_XT_TARGET_TCPMSS=y CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=y # # Xtables matches # CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=y CONFIG_NETFILTER_XT_MATCH_BPF=y CONFIG_NETFILTER_XT_MATCH_CGROUP=y CONFIG_NETFILTER_XT_MATCH_CLUSTER=y CONFIG_NETFILTER_XT_MATCH_COMMENT=y CONFIG_NETFILTER_XT_MATCH_CONNBYTES=y CONFIG_NETFILTER_XT_MATCH_CONNLABEL=y CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=y CONFIG_NETFILTER_XT_MATCH_CONNMARK=y CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y CONFIG_NETFILTER_XT_MATCH_CPU=y CONFIG_NETFILTER_XT_MATCH_DCCP=y CONFIG_NETFILTER_XT_MATCH_DEVGROUP=y CONFIG_NETFILTER_XT_MATCH_DSCP=y CONFIG_NETFILTER_XT_MATCH_ECN=y CONFIG_NETFILTER_XT_MATCH_ESP=y CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=y CONFIG_NETFILTER_XT_MATCH_HELPER=y CONFIG_NETFILTER_XT_MATCH_HL=y CONFIG_NETFILTER_XT_MATCH_IPCOMP=y CONFIG_NETFILTER_XT_MATCH_IPRANGE=y CONFIG_NETFILTER_XT_MATCH_IPVS=y CONFIG_NETFILTER_XT_MATCH_L2TP=y CONFIG_NETFILTER_XT_MATCH_LENGTH=y CONFIG_NETFILTER_XT_MATCH_LIMIT=y CONFIG_NETFILTER_XT_MATCH_MAC=y CONFIG_NETFILTER_XT_MATCH_MARK=y CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y CONFIG_NETFILTER_XT_MATCH_NFACCT=y CONFIG_NETFILTER_XT_MATCH_OSF=y CONFIG_NETFILTER_XT_MATCH_OWNER=y CONFIG_NETFILTER_XT_MATCH_POLICY=y CONFIG_NETFILTER_XT_MATCH_PHYSDEV=y CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y CONFIG_NETFILTER_XT_MATCH_QUOTA=y CONFIG_NETFILTER_XT_MATCH_RATEEST=y CONFIG_NETFILTER_XT_MATCH_REALM=y CONFIG_NETFILTER_XT_MATCH_RECENT=y CONFIG_NETFILTER_XT_MATCH_SCTP=y CONFIG_NETFILTER_XT_MATCH_SOCKET=y CONFIG_NETFILTER_XT_MATCH_STATE=y CONFIG_NETFILTER_XT_MATCH_STATISTIC=y CONFIG_NETFILTER_XT_MATCH_STRING=y CONFIG_NETFILTER_XT_MATCH_TCPMSS=y CONFIG_NETFILTER_XT_MATCH_TIME=y CONFIG_NETFILTER_XT_MATCH_U32=y CONFIG_IP_SET=y CONFIG_IP_SET_MAX=256 CONFIG_IP_SET_BITMAP_IP=y CONFIG_IP_SET_BITMAP_IPMAC=y CONFIG_IP_SET_BITMAP_PORT=y CONFIG_IP_SET_HASH_IP=y CONFIG_IP_SET_HASH_IPMARK=y CONFIG_IP_SET_HASH_IPPORT=y CONFIG_IP_SET_HASH_IPPORTIP=y CONFIG_IP_SET_HASH_IPPORTNET=y CONFIG_IP_SET_HASH_NETPORTNET=y CONFIG_IP_SET_HASH_NET=y CONFIG_IP_SET_HASH_NETNET=y CONFIG_IP_SET_HASH_NETPORT=y CONFIG_IP_SET_HASH_NETIFACE=y CONFIG_IP_SET_LIST_SET=y CONFIG_IP_VS=y CONFIG_IP_VS_IPV6=y CONFIG_IP_VS_DEBUG=y CONFIG_IP_VS_TAB_BITS=12 # # IPVS transport protocol load balancing support # CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_AH_ESP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y CONFIG_IP_VS_PROTO_SCTP=y # # IPVS scheduler # CONFIG_IP_VS_RR=y CONFIG_IP_VS_WRR=y CONFIG_IP_VS_LC=y CONFIG_IP_VS_WLC=y CONFIG_IP_VS_LBLC=y CONFIG_IP_VS_LBLCR=y CONFIG_IP_VS_DH=y CONFIG_IP_VS_SH=y CONFIG_IP_VS_SED=y CONFIG_IP_VS_NQ=y # # IPVS SH scheduler # CONFIG_IP_VS_SH_TAB_BITS=8 # # IPVS application helper # CONFIG_IP_VS_FTP=y CONFIG_IP_VS_NFCT=y CONFIG_IP_VS_PE_SIP=y # # IP: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV4=y CONFIG_NF_CONNTRACK_IPV4=y CONFIG_NF_CONNTRACK_PROC_COMPAT=y CONFIG_NF_LOG_ARP=y CONFIG_NF_LOG_IPV4=y CONFIG_NF_TABLES_IPV4=y CONFIG_NFT_CHAIN_ROUTE_IPV4=y CONFIG_NFT_CHAIN_NAT_IPV4=y CONFIG_NFT_REJECT_IPV4=y CONFIG_NF_TABLES_ARP=y CONFIG_NF_NAT_IPV4=y CONFIG_NF_NAT_SNMP_BASIC=y CONFIG_NF_NAT_PROTO_GRE=y CONFIG_NF_NAT_PPTP=y CONFIG_NF_NAT_H323=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_AH=y CONFIG_IP_NF_MATCH_ECN=y CONFIG_IP_NF_MATCH_RPFILTER=y CONFIG_IP_NF_MATCH_TTL=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_TARGET_SYNPROXY=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_NETMAP=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_CLUSTERIP=y CONFIG_IP_NF_TARGET_ECN=y CONFIG_IP_NF_TARGET_TTL=y CONFIG_IP_NF_RAW=y CONFIG_IP_NF_SECURITY=y CONFIG_IP_NF_ARPTABLES=y CONFIG_IP_NF_ARPFILTER=y CONFIG_IP_NF_ARP_MANGLE=y # # IPv6: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV6=y CONFIG_NF_CONNTRACK_IPV6=y CONFIG_NF_TABLES_IPV6=y CONFIG_NFT_CHAIN_ROUTE_IPV6=y CONFIG_NFT_CHAIN_NAT_IPV6=y CONFIG_NFT_REJECT_IPV6=y CONFIG_NF_LOG_IPV6=y CONFIG_NF_NAT_IPV6=y CONFIG_IP6_NF_IPTABLES=y CONFIG_IP6_NF_MATCH_AH=y CONFIG_IP6_NF_MATCH_EUI64=y CONFIG_IP6_NF_MATCH_FRAG=y CONFIG_IP6_NF_MATCH_OPTS=y CONFIG_IP6_NF_MATCH_HL=y CONFIG_IP6_NF_MATCH_IPV6HEADER=y CONFIG_IP6_NF_MATCH_MH=y CONFIG_IP6_NF_MATCH_RPFILTER=y CONFIG_IP6_NF_MATCH_RT=y CONFIG_IP6_NF_TARGET_HL=y CONFIG_IP6_NF_FILTER=y CONFIG_IP6_NF_TARGET_REJECT=y CONFIG_IP6_NF_TARGET_SYNPROXY=y CONFIG_IP6_NF_MANGLE=y CONFIG_IP6_NF_RAW=y CONFIG_IP6_NF_SECURITY=y CONFIG_IP6_NF_NAT=y CONFIG_IP6_NF_TARGET_MASQUERADE=y CONFIG_IP6_NF_TARGET_NPT=y # # DECnet: Netfilter Configuration # CONFIG_DECNET_NF_GRABULATOR=y CONFIG_NF_TABLES_BRIDGE=y CONFIG_NFT_BRIDGE_META=y CONFIG_NFT_BRIDGE_REJECT=y CONFIG_NF_LOG_BRIDGE=y CONFIG_BRIDGE_NF_EBTABLES=y CONFIG_BRIDGE_EBT_BROUTE=y CONFIG_BRIDGE_EBT_T_FILTER=y CONFIG_BRIDGE_EBT_T_NAT=y CONFIG_BRIDGE_EBT_802_3=y CONFIG_BRIDGE_EBT_AMONG=y CONFIG_BRIDGE_EBT_ARP=y CONFIG_BRIDGE_EBT_IP=y CONFIG_BRIDGE_EBT_IP6=y CONFIG_BRIDGE_EBT_LIMIT=y CONFIG_BRIDGE_EBT_MARK=y CONFIG_BRIDGE_EBT_PKTTYPE=y CONFIG_BRIDGE_EBT_STP=y CONFIG_BRIDGE_EBT_VLAN=y CONFIG_BRIDGE_EBT_ARPREPLY=y CONFIG_BRIDGE_EBT_DNAT=y CONFIG_BRIDGE_EBT_MARK_T=y CONFIG_BRIDGE_EBT_REDIRECT=y CONFIG_BRIDGE_EBT_SNAT=y CONFIG_BRIDGE_EBT_LOG=y CONFIG_BRIDGE_EBT_NFLOG=y CONFIG_IP_DCCP=y CONFIG_INET_DCCP_DIAG=y # # DCCP CCIDs Configuration # CONFIG_IP_DCCP_CCID2_DEBUG=y CONFIG_IP_DCCP_CCID3=y CONFIG_IP_DCCP_CCID3_DEBUG=y CONFIG_IP_DCCP_TFRC_LIB=y CONFIG_IP_DCCP_TFRC_DEBUG=y # # DCCP Kernel Hacking # CONFIG_IP_DCCP_DEBUG=y # CONFIG_NET_DCCPPROBE is not set CONFIG_IP_SCTP=y # CONFIG_NET_SCTPPROBE is not set CONFIG_SCTP_DBG_OBJCNT=y # CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5 is not set CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1=y # CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE is not set CONFIG_SCTP_COOKIE_HMAC_MD5=y CONFIG_SCTP_COOKIE_HMAC_SHA1=y CONFIG_RDS=y CONFIG_RDS_RDMA=y CONFIG_RDS_TCP=y CONFIG_RDS_DEBUG=y CONFIG_TIPC=y CONFIG_TIPC_PORTS=8191 CONFIG_TIPC_MEDIA_IB=y CONFIG_ATM=y CONFIG_ATM_CLIP=y # CONFIG_ATM_CLIP_NO_ICMP is not set CONFIG_ATM_LANE=y CONFIG_ATM_MPOA=y CONFIG_ATM_BR2684=y CONFIG_ATM_BR2684_IPFILTER=y CONFIG_L2TP=y CONFIG_L2TP_DEBUGFS=y CONFIG_L2TP_V3=y CONFIG_L2TP_IP=y CONFIG_L2TP_ETH=y CONFIG_STP=y CONFIG_GARP=y CONFIG_MRP=y CONFIG_BRIDGE=y CONFIG_BRIDGE_IGMP_SNOOPING=y CONFIG_BRIDGE_VLAN_FILTERING=y CONFIG_HAVE_NET_DSA=y CONFIG_NET_DSA=y CONFIG_NET_DSA_TAG_BRCM=y CONFIG_NET_DSA_TAG_DSA=y CONFIG_NET_DSA_TAG_EDSA=y CONFIG_NET_DSA_TAG_TRAILER=y CONFIG_VLAN_8021Q=y CONFIG_VLAN_8021Q_GVRP=y CONFIG_VLAN_8021Q_MVRP=y CONFIG_DECNET=y CONFIG_DECNET_ROUTER=y CONFIG_LLC=y CONFIG_LLC2=y CONFIG_IPX=y CONFIG_IPX_INTERN=y CONFIG_ATALK=y CONFIG_DEV_APPLETALK=y CONFIG_IPDDP=y CONFIG_IPDDP_ENCAP=y CONFIG_X25=y CONFIG_LAPB=y # CONFIG_PHONET is not set CONFIG_6LOWPAN=y CONFIG_IEEE802154=y CONFIG_IEEE802154_6LOWPAN=y CONFIG_MAC802154=y CONFIG_NET_SCHED=y # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=y CONFIG_NET_SCH_HTB=y CONFIG_NET_SCH_HFSC=y CONFIG_NET_SCH_ATM=y CONFIG_NET_SCH_PRIO=y CONFIG_NET_SCH_MULTIQ=y CONFIG_NET_SCH_RED=y CONFIG_NET_SCH_SFB=y CONFIG_NET_SCH_SFQ=y CONFIG_NET_SCH_TEQL=y CONFIG_NET_SCH_TBF=y CONFIG_NET_SCH_GRED=y CONFIG_NET_SCH_DSMARK=y CONFIG_NET_SCH_NETEM=y CONFIG_NET_SCH_DRR=y CONFIG_NET_SCH_MQPRIO=y CONFIG_NET_SCH_CHOKE=y CONFIG_NET_SCH_QFQ=y CONFIG_NET_SCH_CODEL=y CONFIG_NET_SCH_FQ_CODEL=y CONFIG_NET_SCH_FQ=y CONFIG_NET_SCH_HHF=y CONFIG_NET_SCH_PIE=y CONFIG_NET_SCH_INGRESS=y CONFIG_NET_SCH_PLUG=y # # Classification # CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=y CONFIG_NET_CLS_TCINDEX=y CONFIG_NET_CLS_ROUTE4=y CONFIG_NET_CLS_FW=y CONFIG_NET_CLS_U32=y CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=y CONFIG_NET_CLS_RSVP6=y CONFIG_NET_CLS_FLOW=y CONFIG_NET_CLS_CGROUP=y CONFIG_NET_CLS_BPF=y CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=y CONFIG_NET_EMATCH_NBYTE=y CONFIG_NET_EMATCH_U32=y CONFIG_NET_EMATCH_META=y CONFIG_NET_EMATCH_TEXT=y CONFIG_NET_EMATCH_CANID=y CONFIG_NET_EMATCH_IPSET=y CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=y CONFIG_NET_ACT_GACT=y CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=y CONFIG_NET_ACT_IPT=y CONFIG_NET_ACT_NAT=y CONFIG_NET_ACT_PEDIT=y CONFIG_NET_ACT_SIMP=y CONFIG_NET_ACT_SKBEDIT=y CONFIG_NET_ACT_CSUM=y CONFIG_NET_CLS_IND=y CONFIG_NET_SCH_FIFO=y CONFIG_DCB=y CONFIG_DNS_RESOLVER=y # CONFIG_BATMAN_ADV is not set CONFIG_OPENVSWITCH=y CONFIG_OPENVSWITCH_GRE=y CONFIG_OPENVSWITCH_VXLAN=y CONFIG_VSOCKETS=y CONFIG_VMWARE_VMCI_VSOCKETS=y CONFIG_NETLINK_MMAP=y CONFIG_NETLINK_DIAG=y CONFIG_NET_MPLS_GSO=y CONFIG_HSR=y CONFIG_RPS=y CONFIG_RFS_ACCEL=y CONFIG_XPS=y CONFIG_CGROUP_NET_PRIO=y CONFIG_CGROUP_NET_CLASSID=y CONFIG_NET_RX_BUSY_POLL=y CONFIG_BQL=y CONFIG_BPF_JIT=y CONFIG_NET_FLOW_LIMIT=y # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_NET_TCPPROBE is not set CONFIG_NET_DROP_MONITOR=y CONFIG_HAMRADIO=y # # Packet Radio protocols # # CONFIG_AX25 is not set CONFIG_CAN=y CONFIG_CAN_RAW=y CONFIG_CAN_BCM=y CONFIG_CAN_GW=y # # CAN Device Drivers # CONFIG_CAN_VCAN=y CONFIG_CAN_SLCAN=y CONFIG_CAN_DEV=y CONFIG_CAN_CALC_BITTIMING=y CONFIG_CAN_LEDS=y CONFIG_CAN_JANZ_ICAN3=y CONFIG_CAN_SJA1000=y CONFIG_CAN_SJA1000_ISA=y CONFIG_CAN_SJA1000_PLATFORM=y CONFIG_CAN_EMS_PCMCIA=y CONFIG_CAN_EMS_PCI=y CONFIG_CAN_PEAK_PCMCIA=y CONFIG_CAN_PEAK_PCI=y CONFIG_CAN_PEAK_PCIEC=y CONFIG_CAN_KVASER_PCI=y CONFIG_CAN_PLX_PCI=y CONFIG_CAN_C_CAN=y CONFIG_CAN_C_CAN_PLATFORM=y CONFIG_CAN_C_CAN_PCI=y CONFIG_CAN_M_CAN=y CONFIG_CAN_CC770=y CONFIG_CAN_CC770_ISA=y CONFIG_CAN_CC770_PLATFORM=y # # CAN SPI interfaces # CONFIG_CAN_MCP251X=y # # CAN USB interfaces # CONFIG_CAN_EMS_USB=y CONFIG_CAN_ESD_USB2=y CONFIG_CAN_GS_USB=y CONFIG_CAN_KVASER_USB=y CONFIG_CAN_PEAK_USB=y CONFIG_CAN_8DEV_USB=y CONFIG_CAN_SOFTING=y CONFIG_CAN_SOFTING_CS=y CONFIG_CAN_DEBUG_DEVICES=y # CONFIG_IRDA is not set CONFIG_BT=y CONFIG_BT_6LOWPAN=y CONFIG_BT_RFCOMM=y CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=y CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_CMTP=y CONFIG_BT_HIDP=y # # Bluetooth device drivers # CONFIG_BT_HCIBTUSB=y CONFIG_BT_HCIBTSDIO=y CONFIG_BT_HCIUART=y CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_ATH3K=y CONFIG_BT_HCIUART_LL=y CONFIG_BT_HCIUART_3WIRE=y CONFIG_BT_HCIBCM203X=y CONFIG_BT_HCIBPA10X=y CONFIG_BT_HCIBFUSB=y CONFIG_BT_HCIDTL1=y CONFIG_BT_HCIBT3C=y CONFIG_BT_HCIBLUECARD=y CONFIG_BT_HCIBTUART=y CONFIG_BT_HCIVHCI=y CONFIG_BT_MRVL=y CONFIG_BT_MRVL_SDIO=y CONFIG_BT_ATH3K=y CONFIG_BT_WILINK=y CONFIG_AF_RXRPC=y CONFIG_AF_RXRPC_DEBUG=y CONFIG_RXKAD=y CONFIG_FIB_RULES=y CONFIG_WIRELESS=y CONFIG_WIRELESS_EXT=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_WEXT_SPY=y CONFIG_WEXT_PRIV=y CONFIG_CFG80211=y CONFIG_NL80211_TESTMODE=y CONFIG_CFG80211_DEVELOPER_WARNINGS=y CONFIG_CFG80211_REG_DEBUG=y CONFIG_CFG80211_CERTIFICATION_ONUS=y CONFIG_CFG80211_REG_CELLULAR_HINTS=y CONFIG_CFG80211_REG_RELAX_NO_IR=y CONFIG_CFG80211_DEFAULT_PS=y CONFIG_CFG80211_DEBUGFS=y CONFIG_CFG80211_INTERNAL_REGDB=y CONFIG_CFG80211_WEXT=y CONFIG_LIB80211=y CONFIG_LIB80211_CRYPT_WEP=y CONFIG_LIB80211_CRYPT_CCMP=y CONFIG_LIB80211_CRYPT_TKIP=y CONFIG_LIB80211_DEBUG=y CONFIG_MAC80211=y CONFIG_MAC80211_HAS_RC=y CONFIG_MAC80211_RC_MINSTREL=y CONFIG_MAC80211_RC_MINSTREL_HT=y CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT="minstrel_ht" CONFIG_MAC80211_MESH=y CONFIG_MAC80211_LEDS=y CONFIG_MAC80211_DEBUGFS=y CONFIG_MAC80211_MESSAGE_TRACING=y CONFIG_MAC80211_DEBUG_MENU=y CONFIG_MAC80211_NOINLINE=y CONFIG_MAC80211_VERBOSE_DEBUG=y CONFIG_MAC80211_MLME_DEBUG=y CONFIG_MAC80211_STA_DEBUG=y CONFIG_MAC80211_HT_DEBUG=y CONFIG_MAC80211_IBSS_DEBUG=y CONFIG_MAC80211_PS_DEBUG=y CONFIG_MAC80211_MPL_DEBUG=y CONFIG_MAC80211_MPATH_DEBUG=y CONFIG_MAC80211_MHWMP_DEBUG=y CONFIG_MAC80211_MESH_SYNC_DEBUG=y CONFIG_MAC80211_MESH_CSA_DEBUG=y CONFIG_MAC80211_MESH_PS_DEBUG=y CONFIG_MAC80211_TDLS_DEBUG=y CONFIG_MAC80211_DEBUG_COUNTERS=y CONFIG_WIMAX=y CONFIG_WIMAX_DEBUG_LEVEL=8 CONFIG_RFKILL=y CONFIG_RFKILL_LEDS=y CONFIG_RFKILL_INPUT=y CONFIG_RFKILL_REGULATOR=y CONFIG_RFKILL_GPIO=y CONFIG_NET_9P=y CONFIG_NET_9P_VIRTIO=y CONFIG_NET_9P_RDMA=y CONFIG_NET_9P_DEBUG=y CONFIG_CAIF=y CONFIG_CAIF_DEBUG=y CONFIG_CAIF_NETDEV=y CONFIG_CAIF_USB=y CONFIG_CEPH_LIB=y CONFIG_CEPH_LIB_PRETTYDEBUG=y CONFIG_CEPH_LIB_USE_DNS_RESOLVER=y CONFIG_NFC=y CONFIG_NFC_DIGITAL=y CONFIG_NFC_NCI=y CONFIG_NFC_NCI_SPI=y CONFIG_NFC_HCI=y CONFIG_NFC_SHDLC=y # # Near Field Communication (NFC) devices # CONFIG_NFC_PN533=y CONFIG_NFC_WILINK=y CONFIG_NFC_TRF7970A=y CONFIG_NFC_MEI_PHY=y CONFIG_NFC_SIM=y CONFIG_NFC_PORT100=y CONFIG_NFC_PN544=y CONFIG_NFC_PN544_I2C=y CONFIG_NFC_PN544_MEI=y CONFIG_NFC_MICROREAD=y CONFIG_NFC_MICROREAD_I2C=y CONFIG_NFC_MICROREAD_MEI=y CONFIG_NFC_MRVL=y CONFIG_NFC_MRVL_USB=y CONFIG_NFC_ST21NFCA=y CONFIG_NFC_ST21NFCA_I2C=y CONFIG_NFC_ST21NFCB=y CONFIG_NFC_ST21NFCB_I2C=y CONFIG_HAVE_BPF_JIT=y # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" CONFIG_FW_LOADER_USER_HELPER=y CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y CONFIG_DEBUG_DRIVER=y CONFIG_DEBUG_DEVRES=y CONFIG_SYS_HYPERVISOR=y # CONFIG_GENERIC_CPU_DEVICES is not set CONFIG_GENERIC_CPU_AUTOPROBE=y CONFIG_REGMAP=y CONFIG_REGMAP_I2C=y CONFIG_REGMAP_SPI=y CONFIG_REGMAP_MMIO=y CONFIG_REGMAP_IRQ=y CONFIG_DMA_SHARED_BUFFER=y CONFIG_FENCE_TRACE=y CONFIG_DMA_CMA=y # # Default contiguous memory area size: # CONFIG_CMA_SIZE_MBYTES=256 CONFIG_CMA_SIZE_SEL_MBYTES=y # CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set # CONFIG_CMA_SIZE_SEL_MIN is not set # CONFIG_CMA_SIZE_SEL_MAX is not set CONFIG_CMA_ALIGNMENT=8 # # Bus devices # CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y CONFIG_MTD=y CONFIG_MTD_TESTS=m CONFIG_MTD_REDBOOT_PARTS=y CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1 CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED=y CONFIG_MTD_REDBOOT_PARTS_READONLY=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_AR7_PARTS=y # # User Modules And Translation Layers # CONFIG_MTD_BLKDEVS=y CONFIG_MTD_BLOCK=y CONFIG_FTL=y CONFIG_NFTL=y CONFIG_NFTL_RW=y CONFIG_INFTL=y CONFIG_RFD_FTL=y CONFIG_SSFDC=y CONFIG_SM_FTL=y CONFIG_MTD_OOPS=y CONFIG_MTD_SWAP=y # # RAM/ROM/Flash chip drivers # CONFIG_MTD_CFI=y CONFIG_MTD_JEDECPROBE=y CONFIG_MTD_GEN_PROBE=y CONFIG_MTD_CFI_ADV_OPTIONS=y CONFIG_MTD_CFI_NOSWAP=y # CONFIG_MTD_CFI_BE_BYTE_SWAP is not set # CONFIG_MTD_CFI_LE_BYTE_SWAP is not set CONFIG_MTD_CFI_GEOMETRY=y CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y CONFIG_MTD_MAP_BANK_WIDTH_8=y CONFIG_MTD_MAP_BANK_WIDTH_16=y CONFIG_MTD_MAP_BANK_WIDTH_32=y CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y CONFIG_MTD_CFI_I4=y CONFIG_MTD_CFI_I8=y CONFIG_MTD_OTP=y CONFIG_MTD_CFI_INTELEXT=y CONFIG_MTD_CFI_AMDSTD=y CONFIG_MTD_CFI_STAA=y CONFIG_MTD_CFI_UTIL=y CONFIG_MTD_RAM=y CONFIG_MTD_ROM=y CONFIG_MTD_ABSENT=y # # Mapping drivers for chip access # CONFIG_MTD_COMPLEX_MAPPINGS=y CONFIG_MTD_PHYSMAP=y CONFIG_MTD_PHYSMAP_COMPAT=y CONFIG_MTD_PHYSMAP_START=0x8000000 CONFIG_MTD_PHYSMAP_LEN=0 CONFIG_MTD_PHYSMAP_BANKWIDTH=2 CONFIG_MTD_SBC_GXX=y CONFIG_MTD_AMD76XROM=y CONFIG_MTD_ICHXROM=y CONFIG_MTD_ESB2ROM=y CONFIG_MTD_CK804XROM=y CONFIG_MTD_SCB2_FLASH=y CONFIG_MTD_NETtel=y CONFIG_MTD_L440GX=y CONFIG_MTD_PCI=y CONFIG_MTD_PCMCIA=y CONFIG_MTD_PCMCIA_ANONYMOUS=y CONFIG_MTD_GPIO_ADDR=y CONFIG_MTD_INTEL_VR_NOR=y CONFIG_MTD_PLATRAM=y CONFIG_MTD_LATCH_ADDR=y # # Self-contained MTD device drivers # CONFIG_MTD_PMC551=y CONFIG_MTD_PMC551_BUGFIX=y CONFIG_MTD_PMC551_DEBUG=y CONFIG_MTD_DATAFLASH=y CONFIG_MTD_DATAFLASH_WRITE_VERIFY=y CONFIG_MTD_DATAFLASH_OTP=y CONFIG_MTD_M25P80=y CONFIG_MTD_SST25L=y CONFIG_MTD_SLRAM=y CONFIG_MTD_PHRAM=y CONFIG_MTD_MTDRAM=y CONFIG_MTDRAM_TOTAL_SIZE=4096 CONFIG_MTDRAM_ERASE_SIZE=128 CONFIG_MTDRAM_ABS_POS=0 CONFIG_MTD_BLOCK2MTD=y # # Disk-On-Chip Device Drivers # CONFIG_MTD_DOCG3=y CONFIG_BCH_CONST_M=14 CONFIG_BCH_CONST_T=4 CONFIG_MTD_NAND_ECC=y CONFIG_MTD_NAND_ECC_SMC=y CONFIG_MTD_NAND=y CONFIG_MTD_NAND_BCH=y CONFIG_MTD_NAND_ECC_BCH=y CONFIG_MTD_SM_COMMON=y CONFIG_MTD_NAND_DENALI=y CONFIG_MTD_NAND_DENALI_PCI=y CONFIG_MTD_NAND_DENALI_DT=y CONFIG_MTD_NAND_DENALI_SCRATCH_REG_ADDR=0xFF108018 CONFIG_MTD_NAND_GPIO=y CONFIG_MTD_NAND_IDS=y CONFIG_MTD_NAND_RICOH=y CONFIG_MTD_NAND_DISKONCHIP=y CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED=y CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0 CONFIG_MTD_NAND_DISKONCHIP_PROBE_HIGH=y CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE=y CONFIG_MTD_NAND_DOCG4=y CONFIG_MTD_NAND_CAFE=y CONFIG_MTD_NAND_NANDSIM=y CONFIG_MTD_NAND_PLATFORM=y CONFIG_MTD_ONENAND=y CONFIG_MTD_ONENAND_VERIFY_WRITE=y CONFIG_MTD_ONENAND_GENERIC=y CONFIG_MTD_ONENAND_OTP=y CONFIG_MTD_ONENAND_2X_PROGRAM=y # # LPDDR & LPDDR2 PCM memory drivers # CONFIG_MTD_LPDDR=y CONFIG_MTD_QINFO_PROBE=y CONFIG_MTD_SPI_NOR=y CONFIG_MTD_UBI=y CONFIG_MTD_UBI_WL_THRESHOLD=4096 CONFIG_MTD_UBI_BEB_LIMIT=2 CONFIG_MTD_UBI_FASTMAP=y CONFIG_MTD_UBI_GLUEBI=y CONFIG_MTD_UBI_BLOCK=y CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y # CONFIG_PARPORT is not set CONFIG_PNP=y CONFIG_PNP_DEBUG_MESSAGES=y # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_NULL_BLK=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_PCIESSD_MTIP32XX=y CONFIG_ZRAM=y CONFIG_ZRAM_LZ4_COMPRESS=y CONFIG_ZRAM_DEBUG=y CONFIG_BLK_CPQ_CISS_DA=y CONFIG_CISS_SCSI_TAPE=y CONFIG_BLK_DEV_DAC960=y CONFIG_BLK_DEV_UMEM=y # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 CONFIG_BLK_DEV_CRYPTOLOOP=y CONFIG_BLK_DEV_DRBD=y CONFIG_DRBD_FAULT_INJECTION=y CONFIG_BLK_DEV_NBD=y CONFIG_BLK_DEV_NVME=y CONFIG_BLK_DEV_SKD=y CONFIG_BLK_DEV_OSD=y CONFIG_BLK_DEV_SX8=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_BLK_DEV_XIP=y CONFIG_CDROM_PKTCDVD=y CONFIG_CDROM_PKTCDVD_BUFFERS=8 CONFIG_CDROM_PKTCDVD_WCACHE=y CONFIG_ATA_OVER_ETH=y CONFIG_XEN_BLKDEV_FRONTEND=y CONFIG_XEN_BLKDEV_BACKEND=y CONFIG_VIRTIO_BLK=y CONFIG_BLK_DEV_HD=y CONFIG_BLK_DEV_RBD=y CONFIG_BLK_DEV_RSXX=y # # Misc devices # CONFIG_SENSORS_LIS3LV02D=y CONFIG_AD525X_DPOT=y CONFIG_AD525X_DPOT_I2C=y CONFIG_AD525X_DPOT_SPI=y CONFIG_DUMMY_IRQ=y CONFIG_IBM_ASM=y CONFIG_PHANTOM=y CONFIG_SGI_IOC4=y CONFIG_TIFM_CORE=y CONFIG_TIFM_7XX1=y CONFIG_ICS932S401=y CONFIG_ENCLOSURE_SERVICES=y CONFIG_SGI_XP=y CONFIG_HP_ILO=y CONFIG_SGI_GRU=y CONFIG_SGI_GRU_DEBUG=y CONFIG_APDS9802ALS=y CONFIG_ISL29003=y CONFIG_ISL29020=y CONFIG_SENSORS_TSL2550=y CONFIG_SENSORS_BH1780=y CONFIG_SENSORS_BH1770=y CONFIG_SENSORS_APDS990X=y CONFIG_HMC6352=y CONFIG_DS1682=y CONFIG_TI_DAC7512=y CONFIG_VMWARE_BALLOON=y CONFIG_BMP085=y CONFIG_BMP085_I2C=y CONFIG_BMP085_SPI=y CONFIG_USB_SWITCH_FSA9480=y CONFIG_LATTICE_ECP3_CONFIG=y CONFIG_SRAM=y CONFIG_C2PORT=y CONFIG_C2PORT_DURAMAR_2150=y # # EEPROM support # CONFIG_EEPROM_AT24=y CONFIG_EEPROM_AT25=y CONFIG_EEPROM_LEGACY=y CONFIG_EEPROM_MAX6875=y CONFIG_EEPROM_93CX6=y CONFIG_EEPROM_93XX46=y CONFIG_CB710_CORE=y CONFIG_CB710_DEBUG=y CONFIG_CB710_DEBUG_ASSUMPTIONS=y # # Texas Instruments shared transport line discipline # CONFIG_TI_ST=y CONFIG_SENSORS_LIS3_I2C=y # # Altera FPGA firmware download module # CONFIG_ALTERA_STAPL=y CONFIG_INTEL_MEI=y CONFIG_INTEL_MEI_ME=y CONFIG_INTEL_MEI_TXE=y CONFIG_VMWARE_VMCI=y # # Intel MIC Bus Driver # CONFIG_INTEL_MIC_BUS=y # # Intel MIC Host Driver # CONFIG_INTEL_MIC_HOST=y # # Intel MIC Card Driver # CONFIG_INTEL_MIC_CARD=y CONFIG_GENWQE=y CONFIG_GENWQE_PLATFORM_ERROR_RECOVERY=1 CONFIG_ECHO=y CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # CONFIG_SCSI_MOD=y CONFIG_RAID_ATTRS=y CONFIG_SCSI=y CONFIG_SCSI_DMA=y CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_CHR_DEV_OSST=y CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=y CONFIG_CHR_DEV_SCH=y CONFIG_SCSI_ENCLOSURE=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SCAN_ASYNC=y # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=y CONFIG_SCSI_FC_ATTRS=y CONFIG_SCSI_ISCSI_ATTRS=y CONFIG_SCSI_SAS_ATTRS=y CONFIG_SCSI_SAS_LIBSAS=y CONFIG_SCSI_SAS_ATA=y CONFIG_SCSI_SAS_HOST_SMP=y CONFIG_SCSI_SRP_ATTRS=y CONFIG_SCSI_LOWLEVEL=y CONFIG_ISCSI_TCP=y CONFIG_ISCSI_BOOT_SYSFS=y CONFIG_SCSI_CXGB3_ISCSI=y CONFIG_SCSI_CXGB4_ISCSI=y CONFIG_SCSI_BNX2_ISCSI=y CONFIG_SCSI_BNX2X_FCOE=y CONFIG_BE2ISCSI=y CONFIG_BLK_DEV_3W_XXXX_RAID=y CONFIG_SCSI_HPSA=y CONFIG_SCSI_3W_9XXX=y CONFIG_SCSI_3W_SAS=y CONFIG_SCSI_ACARD=y CONFIG_SCSI_AACRAID=y CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=32 CONFIG_AIC7XXX_RESET_DELAY_MS=5000 CONFIG_AIC7XXX_DEBUG_ENABLE=y CONFIG_AIC7XXX_DEBUG_MASK=0 CONFIG_AIC7XXX_REG_PRETTY_PRINT=y CONFIG_SCSI_AIC79XX=y CONFIG_AIC79XX_CMDS_PER_DEVICE=32 CONFIG_AIC79XX_RESET_DELAY_MS=5000 CONFIG_AIC79XX_DEBUG_ENABLE=y CONFIG_AIC79XX_DEBUG_MASK=0 CONFIG_AIC79XX_REG_PRETTY_PRINT=y CONFIG_SCSI_AIC94XX=y CONFIG_AIC94XX_DEBUG=y CONFIG_SCSI_MVSAS=y CONFIG_SCSI_MVSAS_DEBUG=y CONFIG_SCSI_MVSAS_TASKLET=y CONFIG_SCSI_MVUMI=y CONFIG_SCSI_DPT_I2O=y CONFIG_SCSI_ADVANSYS=y CONFIG_SCSI_ARCMSR=y CONFIG_SCSI_ESAS2R=y CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=y CONFIG_MEGARAID_MAILBOX=y CONFIG_MEGARAID_LEGACY=y CONFIG_MEGARAID_SAS=y CONFIG_SCSI_MPT2SAS=y CONFIG_SCSI_MPT2SAS_MAX_SGE=128 CONFIG_SCSI_MPT2SAS_LOGGING=y CONFIG_SCSI_MPT3SAS=y CONFIG_SCSI_MPT3SAS_MAX_SGE=128 CONFIG_SCSI_MPT3SAS_LOGGING=y CONFIG_SCSI_UFSHCD=y CONFIG_SCSI_UFSHCD_PCI=y CONFIG_SCSI_UFSHCD_PLATFORM=y CONFIG_SCSI_HPTIOP=y CONFIG_SCSI_BUSLOGIC=y CONFIG_SCSI_FLASHPOINT=y CONFIG_VMWARE_PVSCSI=y CONFIG_XEN_SCSI_FRONTEND=y CONFIG_HYPERV_STORAGE=y CONFIG_LIBFC=y CONFIG_LIBFCOE=y CONFIG_FCOE=y CONFIG_FCOE_FNIC=y CONFIG_SCSI_DMX3191D=y CONFIG_SCSI_EATA=y CONFIG_SCSI_EATA_TAGGED_QUEUE=y CONFIG_SCSI_EATA_LINKED_COMMANDS=y CONFIG_SCSI_EATA_MAX_TAGS=16 CONFIG_SCSI_FUTURE_DOMAIN=y CONFIG_SCSI_GDTH=y CONFIG_SCSI_ISCI=y CONFIG_SCSI_IPS=y CONFIG_SCSI_INITIO=y CONFIG_SCSI_INIA100=y CONFIG_SCSI_STEX=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 CONFIG_SCSI_SYM53C8XX_MMIO=y CONFIG_SCSI_IPR=y CONFIG_SCSI_IPR_TRACE=y CONFIG_SCSI_IPR_DUMP=y CONFIG_SCSI_QLOGIC_1280=y CONFIG_SCSI_QLA_FC=y CONFIG_TCM_QLA2XXX=y CONFIG_SCSI_QLA_ISCSI=y # CONFIG_SCSI_LPFC is not set CONFIG_SCSI_DC395x=y CONFIG_SCSI_DC390T=y CONFIG_SCSI_DEBUG=y CONFIG_SCSI_PMCRAID=y CONFIG_SCSI_PM8001=y CONFIG_SCSI_BFA_FC=y CONFIG_SCSI_VIRTIO=y CONFIG_SCSI_CHELSIO_FCOE=y CONFIG_SCSI_LOWLEVEL_PCMCIA=y CONFIG_PCMCIA_AHA152X=m CONFIG_PCMCIA_FDOMAIN=m CONFIG_PCMCIA_QLOGIC=m CONFIG_PCMCIA_SYM53C500=m CONFIG_SCSI_DH=y CONFIG_SCSI_DH_RDAC=y CONFIG_SCSI_DH_HP_SW=y CONFIG_SCSI_DH_EMC=y CONFIG_SCSI_DH_ALUA=y CONFIG_SCSI_OSD_INITIATOR=y CONFIG_SCSI_OSD_ULD=y CONFIG_SCSI_OSD_DPRINT_SENSE=1 # CONFIG_SCSI_OSD_DEBUG is not set CONFIG_ATA=y # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_VERBOSE_ERROR=y CONFIG_ATA_ACPI=y CONFIG_SATA_ZPODD=y CONFIG_SATA_PMP=y # # Controllers with non-SFF native interface # CONFIG_SATA_AHCI=y CONFIG_SATA_AHCI_PLATFORM=y CONFIG_SATA_INIC162X=y CONFIG_SATA_ACARD_AHCI=y CONFIG_SATA_SIL24=y CONFIG_ATA_SFF=y # # SFF controllers with custom DMA interface # CONFIG_PDC_ADMA=y CONFIG_SATA_QSTOR=y CONFIG_SATA_SX4=y CONFIG_ATA_BMDMA=y # # SATA SFF controllers with BMDMA # CONFIG_ATA_PIIX=y CONFIG_SATA_MV=y CONFIG_SATA_NV=y CONFIG_SATA_PROMISE=y CONFIG_SATA_SIL=y CONFIG_SATA_SIS=y CONFIG_SATA_SVW=y CONFIG_SATA_ULI=y CONFIG_SATA_VIA=y CONFIG_SATA_VITESSE=y # # PATA SFF controllers with BMDMA # CONFIG_PATA_ALI=y CONFIG_PATA_AMD=y CONFIG_PATA_ARTOP=y CONFIG_PATA_ATIIXP=y CONFIG_PATA_ATP867X=y CONFIG_PATA_CMD64X=y CONFIG_PATA_CYPRESS=y CONFIG_PATA_EFAR=y CONFIG_PATA_HPT366=y CONFIG_PATA_HPT37X=y CONFIG_PATA_HPT3X2N=y CONFIG_PATA_HPT3X3=y CONFIG_PATA_HPT3X3_DMA=y CONFIG_PATA_IT8213=y CONFIG_PATA_IT821X=y CONFIG_PATA_JMICRON=y CONFIG_PATA_MARVELL=y CONFIG_PATA_NETCELL=y CONFIG_PATA_NINJA32=y CONFIG_PATA_NS87415=y CONFIG_PATA_OLDPIIX=y CONFIG_PATA_OPTIDMA=y CONFIG_PATA_PDC2027X=y CONFIG_PATA_PDC_OLD=y CONFIG_PATA_RADISYS=y CONFIG_PATA_RDC=y CONFIG_PATA_SCH=y CONFIG_PATA_SERVERWORKS=y CONFIG_PATA_SIL680=y CONFIG_PATA_SIS=y CONFIG_PATA_TOSHIBA=y CONFIG_PATA_TRIFLEX=y CONFIG_PATA_VIA=y CONFIG_PATA_WINBOND=y # # PIO-only SFF controllers # CONFIG_PATA_CMD640_PCI=y CONFIG_PATA_MPIIX=y CONFIG_PATA_NS87410=y CONFIG_PATA_OPTI=y CONFIG_PATA_PCMCIA=y CONFIG_PATA_PLATFORM=y CONFIG_PATA_RZ1000=y # # Generic fallback / legacy drivers # CONFIG_PATA_ACPI=y CONFIG_ATA_GENERIC=y # CONFIG_PATA_LEGACY is not set CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_AUTODETECT=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID10=y CONFIG_MD_RAID456=y CONFIG_MD_MULTIPATH=y CONFIG_MD_FAULTY=y CONFIG_BCACHE=y CONFIG_BCACHE_DEBUG=y CONFIG_BCACHE_CLOSURES_DEBUG=y CONFIG_BLK_DEV_DM_BUILTIN=y CONFIG_BLK_DEV_DM=y CONFIG_DM_DEBUG=y CONFIG_DM_BUFIO=y CONFIG_DM_BIO_PRISON=y CONFIG_DM_PERSISTENT_DATA=y CONFIG_DM_DEBUG_BLOCK_STACK_TRACING=y CONFIG_DM_CRYPT=y CONFIG_DM_SNAPSHOT=y CONFIG_DM_THIN_PROVISIONING=y CONFIG_DM_CACHE=y CONFIG_DM_CACHE_MQ=y CONFIG_DM_CACHE_CLEANER=y CONFIG_DM_ERA=y CONFIG_DM_MIRROR=y CONFIG_DM_LOG_USERSPACE=y CONFIG_DM_RAID=y CONFIG_DM_ZERO=y CONFIG_DM_MULTIPATH=y CONFIG_DM_MULTIPATH_QL=y CONFIG_DM_MULTIPATH_ST=y CONFIG_DM_DELAY=y CONFIG_DM_UEVENT=y CONFIG_DM_FLAKEY=y CONFIG_DM_VERITY=y CONFIG_DM_SWITCH=y CONFIG_TARGET_CORE=y CONFIG_TCM_IBLOCK=y CONFIG_TCM_FILEIO=y CONFIG_TCM_PSCSI=y CONFIG_LOOPBACK_TARGET=y CONFIG_TCM_FC=y CONFIG_ISCSI_TARGET=y CONFIG_SBP_TARGET=y CONFIG_FUSION=y CONFIG_FUSION_SPI=y CONFIG_FUSION_FC=y CONFIG_FUSION_SAS=y CONFIG_FUSION_MAX_SGE=128 CONFIG_FUSION_CTL=y CONFIG_FUSION_LAN=y CONFIG_FUSION_LOGGING=y # # IEEE 1394 (FireWire) support # CONFIG_FIREWIRE=y CONFIG_FIREWIRE_OHCI=y CONFIG_FIREWIRE_SBP2=y CONFIG_FIREWIRE_NET=y CONFIG_FIREWIRE_NOSY=y CONFIG_I2O=y CONFIG_I2O_LCT_NOTIFY_ON_CHANGES=y CONFIG_I2O_EXT_ADAPTEC=y CONFIG_I2O_EXT_ADAPTEC_DMA64=y CONFIG_I2O_CONFIG=y CONFIG_I2O_CONFIG_OLD_IOCTL=y CONFIG_I2O_BUS=y CONFIG_I2O_BLOCK=y CONFIG_I2O_SCSI=y CONFIG_I2O_PROC=y CONFIG_MACINTOSH_DRIVERS=y CONFIG_MAC_EMUMOUSEBTN=y CONFIG_NETDEVICES=y CONFIG_MII=y CONFIG_NET_CORE=y CONFIG_BONDING=y CONFIG_DUMMY=y CONFIG_EQUALIZER=y CONFIG_NET_FC=y CONFIG_IFB=y CONFIG_NET_TEAM=y CONFIG_NET_TEAM_MODE_BROADCAST=y CONFIG_NET_TEAM_MODE_ROUNDROBIN=y CONFIG_NET_TEAM_MODE_RANDOM=y CONFIG_NET_TEAM_MODE_ACTIVEBACKUP=y CONFIG_NET_TEAM_MODE_LOADBALANCE=y CONFIG_MACVLAN=y CONFIG_MACVTAP=y CONFIG_VXLAN=y CONFIG_NETCONSOLE=y CONFIG_NETCONSOLE_DYNAMIC=y CONFIG_NETPOLL=y CONFIG_NET_POLL_CONTROLLER=y CONFIG_NTB_NETDEV=y CONFIG_RIONET=y CONFIG_RIONET_TX_SIZE=128 CONFIG_RIONET_RX_SIZE=128 CONFIG_TUN=y CONFIG_VETH=y CONFIG_VIRTIO_NET=y CONFIG_NLMON=y CONFIG_SUNGEM_PHY=y CONFIG_ARCNET=y CONFIG_ARCNET_1201=y CONFIG_ARCNET_1051=y CONFIG_ARCNET_RAW=y CONFIG_ARCNET_CAP=y CONFIG_ARCNET_COM90xx=y CONFIG_ARCNET_COM90xxIO=y CONFIG_ARCNET_RIM_I=y CONFIG_ARCNET_COM20020=y CONFIG_ARCNET_COM20020_PCI=y CONFIG_ARCNET_COM20020_CS=y CONFIG_ATM_DRIVERS=y CONFIG_ATM_DUMMY=y CONFIG_ATM_TCP=y CONFIG_ATM_LANAI=y CONFIG_ATM_ENI=y CONFIG_ATM_ENI_DEBUG=y CONFIG_ATM_ENI_TUNE_BURST=y CONFIG_ATM_ENI_BURST_TX_16W=y CONFIG_ATM_ENI_BURST_TX_8W=y CONFIG_ATM_ENI_BURST_TX_4W=y CONFIG_ATM_ENI_BURST_TX_2W=y CONFIG_ATM_ENI_BURST_RX_16W=y CONFIG_ATM_ENI_BURST_RX_8W=y CONFIG_ATM_ENI_BURST_RX_4W=y CONFIG_ATM_ENI_BURST_RX_2W=y CONFIG_ATM_FIRESTREAM=y CONFIG_ATM_ZATM=y CONFIG_ATM_ZATM_DEBUG=y CONFIG_ATM_NICSTAR=y CONFIG_ATM_NICSTAR_USE_SUNI=y CONFIG_ATM_NICSTAR_USE_IDT77105=y CONFIG_ATM_IDT77252=y CONFIG_ATM_IDT77252_DEBUG=y CONFIG_ATM_IDT77252_RCV_ALL=y CONFIG_ATM_IDT77252_USE_SUNI=y CONFIG_ATM_AMBASSADOR=y CONFIG_ATM_AMBASSADOR_DEBUG=y CONFIG_ATM_HORIZON=y CONFIG_ATM_HORIZON_DEBUG=y CONFIG_ATM_IA=y CONFIG_ATM_IA_DEBUG=y CONFIG_ATM_FORE200E=y CONFIG_ATM_FORE200E_USE_TASKLET=y CONFIG_ATM_FORE200E_TX_RETRY=16 CONFIG_ATM_FORE200E_DEBUG=0 CONFIG_ATM_HE=y CONFIG_ATM_HE_USE_SUNI=y CONFIG_ATM_SOLOS=y # # CAIF transport drivers # CONFIG_CAIF_TTY=y CONFIG_CAIF_SPI_SLAVE=y CONFIG_CAIF_SPI_SYNC=y CONFIG_CAIF_HSI=y CONFIG_CAIF_VIRTIO=y CONFIG_VHOST_NET=y CONFIG_VHOST_SCSI=m CONFIG_VHOST_RING=y CONFIG_VHOST=y # # Distributed Switch Architecture drivers # CONFIG_NET_DSA_MV88E6XXX=y CONFIG_NET_DSA_MV88E6060=y CONFIG_NET_DSA_MV88E6XXX_NEED_PPU=y CONFIG_NET_DSA_MV88E6131=y CONFIG_NET_DSA_MV88E6123_61_65=y CONFIG_NET_DSA_BCM_SF2=y CONFIG_ETHERNET=y CONFIG_MDIO=y CONFIG_NET_VENDOR_3COM=y CONFIG_PCMCIA_3C574=y CONFIG_PCMCIA_3C589=y CONFIG_VORTEX=y CONFIG_TYPHOON=y CONFIG_NET_VENDOR_ADAPTEC=y CONFIG_ADAPTEC_STARFIRE=y CONFIG_NET_VENDOR_ALTEON=y CONFIG_ACENIC=y CONFIG_ACENIC_OMIT_TIGON_I=y CONFIG_ALTERA_TSE=y CONFIG_NET_VENDOR_AMD=y CONFIG_AMD8111_ETH=y CONFIG_PCNET32=y CONFIG_PCMCIA_NMCLAN=y CONFIG_NET_XGENE=y CONFIG_NET_VENDOR_ARC=y CONFIG_NET_VENDOR_ATHEROS=y CONFIG_ATL2=y CONFIG_ATL1=y CONFIG_ATL1E=y CONFIG_ATL1C=y CONFIG_ALX=y CONFIG_NET_VENDOR_BROADCOM=y CONFIG_B44=y CONFIG_B44_PCI_AUTOSELECT=y CONFIG_B44_PCICORE_AUTOSELECT=y CONFIG_B44_PCI=y CONFIG_BNX2=y CONFIG_CNIC=y CONFIG_TIGON3=y CONFIG_BNX2X=y CONFIG_BNX2X_SRIOV=y CONFIG_NET_VENDOR_BROCADE=y CONFIG_BNA=y CONFIG_NET_VENDOR_CHELSIO=y CONFIG_CHELSIO_T1=y CONFIG_CHELSIO_T1_1G=y CONFIG_CHELSIO_T3=y CONFIG_CHELSIO_T4=y CONFIG_CHELSIO_T4_DCB=y CONFIG_CHELSIO_T4VF=y CONFIG_NET_VENDOR_CISCO=y CONFIG_ENIC=y CONFIG_CX_ECAT=y CONFIG_DNET=y CONFIG_NET_VENDOR_DEC=y CONFIG_NET_TULIP=y CONFIG_DE2104X=y CONFIG_DE2104X_DSL=0 CONFIG_TULIP=y CONFIG_TULIP_MWI=y CONFIG_TULIP_MMIO=y CONFIG_TULIP_NAPI=y CONFIG_TULIP_NAPI_HW_MITIGATION=y CONFIG_DE4X5=y CONFIG_WINBOND_840=y CONFIG_DM9102=y CONFIG_ULI526X=y CONFIG_PCMCIA_XIRCOM=y CONFIG_NET_VENDOR_DLINK=y CONFIG_DL2K=y CONFIG_SUNDANCE=y CONFIG_SUNDANCE_MMIO=y CONFIG_NET_VENDOR_EMULEX=y CONFIG_BE2NET=y CONFIG_BE2NET_VXLAN=y CONFIG_NET_VENDOR_EXAR=y CONFIG_S2IO=y CONFIG_VXGE=y CONFIG_VXGE_DEBUG_TRACE_ALL=y CONFIG_NET_VENDOR_FUJITSU=y CONFIG_PCMCIA_FMVJ18X=y CONFIG_NET_VENDOR_HP=y CONFIG_HP100=y CONFIG_NET_VENDOR_INTEL=y CONFIG_E100=y CONFIG_E1000=y CONFIG_E1000E=y CONFIG_IGB=y CONFIG_IGB_HWMON=y CONFIG_IGB_DCA=y CONFIG_IGBVF=y CONFIG_IXGB=y CONFIG_IXGBE=y CONFIG_IXGBE_HWMON=y CONFIG_IXGBE_DCA=y CONFIG_IXGBE_DCB=y CONFIG_IXGBEVF=y CONFIG_I40E=y CONFIG_I40E_VXLAN=y CONFIG_I40E_DCB=y # CONFIG_I40EVF is not set CONFIG_NET_VENDOR_I825XX=y CONFIG_IP1000=y CONFIG_JME=y CONFIG_NET_VENDOR_MARVELL=y CONFIG_MVMDIO=y CONFIG_SKGE=y CONFIG_SKGE_DEBUG=y CONFIG_SKGE_GENESIS=y CONFIG_SKY2=y CONFIG_SKY2_DEBUG=y CONFIG_NET_VENDOR_MELLANOX=y CONFIG_MLX4_EN=y CONFIG_MLX4_EN_DCB=y CONFIG_MLX4_EN_VXLAN=y CONFIG_MLX4_CORE=y CONFIG_MLX4_DEBUG=y CONFIG_MLX5_CORE=y CONFIG_NET_VENDOR_MICREL=y CONFIG_KS8842=y CONFIG_KS8851=y CONFIG_KS8851_MLL=y CONFIG_KSZ884X_PCI=y CONFIG_NET_VENDOR_MICROCHIP=y CONFIG_ENC28J60=y CONFIG_ENC28J60_WRITEVERIFY=y CONFIG_NET_VENDOR_MYRI=y CONFIG_MYRI10GE=y CONFIG_MYRI10GE_DCA=y CONFIG_FEALNX=y CONFIG_NET_VENDOR_NATSEMI=y CONFIG_NATSEMI=y CONFIG_NS83820=y CONFIG_NET_VENDOR_8390=y CONFIG_PCMCIA_AXNET=y CONFIG_NE2K_PCI=y CONFIG_PCMCIA_PCNET=y CONFIG_NET_VENDOR_NVIDIA=y CONFIG_FORCEDETH=y CONFIG_NET_VENDOR_OKI=y CONFIG_ETHOC=y CONFIG_NET_PACKET_ENGINE=y CONFIG_HAMACHI=y CONFIG_YELLOWFIN=y CONFIG_NET_VENDOR_QLOGIC=y CONFIG_QLA3XXX=y CONFIG_QLCNIC=y CONFIG_QLCNIC_SRIOV=y CONFIG_QLCNIC_DCB=y CONFIG_QLCNIC_VXLAN=y CONFIG_QLCNIC_HWMON=y CONFIG_QLGE=y CONFIG_NETXEN_NIC=y CONFIG_NET_VENDOR_REALTEK=y CONFIG_8139CP=y CONFIG_8139TOO=y CONFIG_8139TOO_PIO=y CONFIG_8139TOO_TUNE_TWISTER=y CONFIG_8139TOO_8129=y CONFIG_8139_OLD_RX_RESET=y CONFIG_R8169=y CONFIG_NET_VENDOR_RDC=y CONFIG_R6040=y CONFIG_NET_VENDOR_SAMSUNG=y CONFIG_SXGBE_ETH=y CONFIG_NET_VENDOR_SEEQ=y CONFIG_NET_VENDOR_SILAN=y CONFIG_SC92031=y CONFIG_NET_VENDOR_SIS=y CONFIG_SIS900=y CONFIG_SIS190=y CONFIG_SFC=y CONFIG_SFC_MTD=y CONFIG_SFC_MCDI_MON=y CONFIG_SFC_SRIOV=y CONFIG_NET_VENDOR_SMSC=y CONFIG_PCMCIA_SMC91C92=y CONFIG_EPIC100=y CONFIG_SMSC911X=y # CONFIG_SMSC911X_ARCH_HOOKS is not set CONFIG_SMSC9420=y CONFIG_NET_VENDOR_STMICRO=y CONFIG_STMMAC_ETH=y CONFIG_STMMAC_PLATFORM=y CONFIG_STMMAC_PCI=y CONFIG_STMMAC_DEBUG_FS=y CONFIG_STMMAC_DA=y CONFIG_NET_VENDOR_SUN=y CONFIG_HAPPYMEAL=y CONFIG_SUNGEM=y CONFIG_CASSINI=y CONFIG_NIU=y CONFIG_NET_VENDOR_TEHUTI=y CONFIG_TEHUTI=y CONFIG_NET_VENDOR_TI=y CONFIG_TLAN=y CONFIG_NET_VENDOR_VIA=y CONFIG_VIA_RHINE=y CONFIG_VIA_RHINE_MMIO=y CONFIG_VIA_VELOCITY=y CONFIG_NET_VENDOR_WIZNET=y CONFIG_WIZNET_W5100=y CONFIG_WIZNET_W5300=y # CONFIG_WIZNET_BUS_DIRECT is not set # CONFIG_WIZNET_BUS_INDIRECT is not set CONFIG_WIZNET_BUS_ANY=y CONFIG_NET_VENDOR_XIRCOM=y CONFIG_PCMCIA_XIRC2PS=y CONFIG_FDDI=y CONFIG_DEFXX=y CONFIG_DEFXX_MMIO=y CONFIG_SKFP=y CONFIG_HIPPI=y CONFIG_ROADRUNNER=y CONFIG_ROADRUNNER_LARGE_RINGS=y CONFIG_NET_SB1000=y CONFIG_PHYLIB=y # # MII PHY device drivers # CONFIG_AT803X_PHY=y CONFIG_AMD_PHY=y CONFIG_MARVELL_PHY=y CONFIG_DAVICOM_PHY=y CONFIG_QSEMI_PHY=y CONFIG_LXT_PHY=y CONFIG_CICADA_PHY=y CONFIG_VITESSE_PHY=y CONFIG_SMSC_PHY=y CONFIG_BROADCOM_PHY=y CONFIG_BCM7XXX_PHY=y CONFIG_BCM87XX_PHY=y CONFIG_ICPLUS_PHY=y CONFIG_REALTEK_PHY=y CONFIG_NATIONAL_PHY=y CONFIG_STE10XP=y CONFIG_LSI_ET1011C_PHY=y CONFIG_MICREL_PHY=y CONFIG_FIXED_PHY=y CONFIG_MDIO_BITBANG=y CONFIG_MDIO_GPIO=y CONFIG_MDIO_BCM_UNIMAC=y CONFIG_MICREL_KS8995MA=y CONFIG_PPP=y CONFIG_PPP_BSDCOMP=y CONFIG_PPP_DEFLATE=y CONFIG_PPP_FILTER=y CONFIG_PPP_MPPE=y CONFIG_PPP_MULTILINK=y CONFIG_PPPOATM=y CONFIG_PPPOE=y CONFIG_PPTP=y CONFIG_PPPOL2TP=y CONFIG_PPP_ASYNC=y CONFIG_PPP_SYNC_TTY=y CONFIG_SLIP=y CONFIG_SLHC=y CONFIG_SLIP_COMPRESSED=y CONFIG_SLIP_SMART=y CONFIG_SLIP_MODE_SLIP6=y CONFIG_USB_NET_DRIVERS=y CONFIG_USB_CATC=y CONFIG_USB_KAWETH=y CONFIG_USB_PEGASUS=y CONFIG_USB_RTL8150=y CONFIG_USB_RTL8152=y CONFIG_USB_USBNET=y CONFIG_USB_NET_AX8817X=y CONFIG_USB_NET_AX88179_178A=y CONFIG_USB_NET_CDCETHER=y CONFIG_USB_NET_CDC_EEM=y CONFIG_USB_NET_CDC_NCM=y CONFIG_USB_NET_HUAWEI_CDC_NCM=y CONFIG_USB_NET_CDC_MBIM=y CONFIG_USB_NET_DM9601=y CONFIG_USB_NET_SR9700=y CONFIG_USB_NET_SR9800=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y CONFIG_USB_NET_GL620A=y CONFIG_USB_NET_NET1080=y CONFIG_USB_NET_PLUSB=y CONFIG_USB_NET_MCS7830=y CONFIG_USB_NET_RNDIS_HOST=y CONFIG_USB_NET_CDC_SUBSET=y CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y CONFIG_USB_NET_ZAURUS=y CONFIG_USB_NET_CX82310_ETH=y CONFIG_USB_NET_KALMIA=y CONFIG_USB_NET_QMI_WWAN=y CONFIG_USB_HSO=y CONFIG_USB_NET_INT51X1=y CONFIG_USB_IPHETH=y CONFIG_USB_SIERRA_NET=y CONFIG_USB_VL600=y CONFIG_WLAN=y CONFIG_PCMCIA_RAYCS=y CONFIG_LIBERTAS_THINFIRM=y CONFIG_LIBERTAS_THINFIRM_DEBUG=y CONFIG_LIBERTAS_THINFIRM_USB=y CONFIG_AIRO=y CONFIG_ATMEL=y CONFIG_PCI_ATMEL=y CONFIG_PCMCIA_ATMEL=y CONFIG_AT76C50X_USB=y CONFIG_AIRO_CS=y CONFIG_PCMCIA_WL3501=y CONFIG_PRISM54=y CONFIG_USB_ZD1201=y CONFIG_USB_NET_RNDIS_WLAN=y CONFIG_RTL8180=y CONFIG_RTL8187=y CONFIG_RTL8187_LEDS=y CONFIG_ADM8211=y CONFIG_MAC80211_HWSIM=y CONFIG_MWL8K=y CONFIG_ATH_COMMON=y CONFIG_ATH_CARDS=y CONFIG_ATH_DEBUG=y CONFIG_ATH_REG_DYNAMIC_USER_REG_HINTS=y CONFIG_ATH_REG_DYNAMIC_USER_CERT_TESTING=y CONFIG_ATH5K=y CONFIG_ATH5K_DEBUG=y CONFIG_ATH5K_TRACER=y CONFIG_ATH5K_PCI=y CONFIG_ATH5K_TEST_CHANNELS=y CONFIG_ATH9K_HW=y CONFIG_ATH9K_COMMON=y CONFIG_ATH9K_DFS_DEBUGFS=y CONFIG_ATH9K_BTCOEX_SUPPORT=y CONFIG_ATH9K=y CONFIG_ATH9K_PCI=y CONFIG_ATH9K_AHB=y CONFIG_ATH9K_DEBUGFS=y CONFIG_ATH9K_STATION_STATISTICS=y CONFIG_ATH9K_DFS_CERTIFIED=y CONFIG_ATH9K_TX99=y CONFIG_ATH9K_WOW=y CONFIG_ATH9K_RFKILL=y CONFIG_ATH9K_CHANNEL_CONTEXT=y CONFIG_ATH9K_HTC=y CONFIG_ATH9K_HTC_DEBUGFS=y CONFIG_CARL9170=y CONFIG_CARL9170_LEDS=y CONFIG_CARL9170_DEBUGFS=y CONFIG_CARL9170_WPC=y CONFIG_CARL9170_HWRNG=y CONFIG_ATH6KL=y # CONFIG_ATH6KL_SDIO is not set # CONFIG_ATH6KL_USB is not set # CONFIG_ATH6KL_DEBUG is not set CONFIG_ATH6KL_TRACING=y CONFIG_ATH6KL_REGDOMAIN=y CONFIG_AR5523=y CONFIG_WIL6210=y CONFIG_WIL6210_ISR_COR=y CONFIG_WIL6210_TRACING=y CONFIG_ATH10K=y CONFIG_ATH10K_PCI=y CONFIG_ATH10K_DEBUG=y CONFIG_ATH10K_DEBUGFS=y CONFIG_ATH10K_TRACING=y CONFIG_ATH10K_DFS_CERTIFIED=y CONFIG_WCN36XX=y CONFIG_WCN36XX_DEBUGFS=y CONFIG_B43=y CONFIG_B43_BCMA=y CONFIG_B43_SSB=y CONFIG_B43_BUSES_BCMA_AND_SSB=y # CONFIG_B43_BUSES_BCMA is not set # CONFIG_B43_BUSES_SSB is not set CONFIG_B43_PCI_AUTOSELECT=y CONFIG_B43_PCICORE_AUTOSELECT=y CONFIG_B43_PCMCIA=y CONFIG_B43_SDIO=y CONFIG_B43_BCMA_PIO=y CONFIG_B43_PIO=y CONFIG_B43_PHY_G=y CONFIG_B43_PHY_N=y CONFIG_B43_PHY_LP=y CONFIG_B43_PHY_HT=y CONFIG_B43_LEDS=y CONFIG_B43_HWRNG=y CONFIG_B43_DEBUG=y CONFIG_B43LEGACY=y CONFIG_B43LEGACY_PCI_AUTOSELECT=y CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y CONFIG_B43LEGACY_LEDS=y CONFIG_B43LEGACY_HWRNG=y CONFIG_B43LEGACY_DEBUG=y CONFIG_B43LEGACY_DMA=y CONFIG_B43LEGACY_PIO=y CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y # CONFIG_B43LEGACY_DMA_MODE is not set # CONFIG_B43LEGACY_PIO_MODE is not set CONFIG_BRCMUTIL=y CONFIG_BRCMSMAC=y CONFIG_BRCMFMAC=y CONFIG_BRCMFMAC_SDIO=y CONFIG_BRCMFMAC_USB=y CONFIG_BRCMFMAC_PCIE=y CONFIG_BRCM_TRACING=y CONFIG_BRCMDBG=y CONFIG_HOSTAP=y CONFIG_HOSTAP_FIRMWARE=y CONFIG_HOSTAP_FIRMWARE_NVRAM=y CONFIG_HOSTAP_PLX=y CONFIG_HOSTAP_PCI=y CONFIG_HOSTAP_CS=y CONFIG_IPW2100=y CONFIG_IPW2100_MONITOR=y CONFIG_IPW2100_DEBUG=y CONFIG_IPW2200=y CONFIG_IPW2200_MONITOR=y CONFIG_IPW2200_RADIOTAP=y CONFIG_IPW2200_PROMISCUOUS=y CONFIG_IPW2200_QOS=y CONFIG_IPW2200_DEBUG=y CONFIG_LIBIPW=y CONFIG_LIBIPW_DEBUG=y CONFIG_IWLWIFI=y CONFIG_IWLWIFI_LEDS=y CONFIG_IWLDVM=m CONFIG_IWLMVM=m CONFIG_IWLWIFI_OPMODE_MODULAR=y CONFIG_IWLWIFI_BCAST_FILTERING=y CONFIG_IWLWIFI_UAPSD=y # # Debugging Options # CONFIG_IWLWIFI_DEBUG=y CONFIG_IWLWIFI_DEBUGFS=y CONFIG_IWLWIFI_DEBUG_EXPERIMENTAL_UCODE=y CONFIG_IWLWIFI_DEVICE_TRACING=y CONFIG_IWLEGACY=y CONFIG_IWL4965=y CONFIG_IWL3945=y # # iwl3945 / iwl4965 Debugging Options # CONFIG_IWLEGACY_DEBUG=y CONFIG_IWLEGACY_DEBUGFS=y CONFIG_LIBERTAS=y CONFIG_LIBERTAS_USB=y CONFIG_LIBERTAS_CS=y CONFIG_LIBERTAS_SDIO=y CONFIG_LIBERTAS_SPI=y CONFIG_LIBERTAS_DEBUG=y CONFIG_LIBERTAS_MESH=y CONFIG_HERMES=y CONFIG_HERMES_PRISM=y CONFIG_HERMES_CACHE_FW_ON_INIT=y CONFIG_PLX_HERMES=y CONFIG_TMD_HERMES=y CONFIG_NORTEL_HERMES=y CONFIG_PCI_HERMES=y CONFIG_PCMCIA_HERMES=y CONFIG_PCMCIA_SPECTRUM=y CONFIG_ORINOCO_USB=y CONFIG_P54_COMMON=y CONFIG_P54_USB=y CONFIG_P54_PCI=y CONFIG_P54_SPI=y CONFIG_P54_SPI_DEFAULT_EEPROM=y CONFIG_P54_LEDS=y CONFIG_RT2X00=y CONFIG_RT2400PCI=y CONFIG_RT2500PCI=y CONFIG_RT61PCI=y CONFIG_RT2800PCI=y CONFIG_RT2800PCI_RT33XX=y CONFIG_RT2800PCI_RT35XX=y CONFIG_RT2800PCI_RT53XX=y CONFIG_RT2800PCI_RT3290=y CONFIG_RT2500USB=y CONFIG_RT73USB=y CONFIG_RT2800USB=y CONFIG_RT2800USB_RT33XX=y CONFIG_RT2800USB_RT35XX=y CONFIG_RT2800USB_RT3573=y CONFIG_RT2800USB_RT53XX=y CONFIG_RT2800USB_RT55XX=y CONFIG_RT2800USB_UNKNOWN=y CONFIG_RT2800_LIB=y CONFIG_RT2800_LIB_MMIO=y CONFIG_RT2X00_LIB_MMIO=y CONFIG_RT2X00_LIB_PCI=y CONFIG_RT2X00_LIB_USB=y CONFIG_RT2X00_LIB=y CONFIG_RT2X00_LIB_FIRMWARE=y CONFIG_RT2X00_LIB_CRYPTO=y CONFIG_RT2X00_LIB_LEDS=y CONFIG_RT2X00_LIB_DEBUGFS=y CONFIG_RT2X00_DEBUG=y CONFIG_RTL_CARDS=y CONFIG_RTL8192CE=y CONFIG_RTL8192SE=y CONFIG_RTL8192DE=y CONFIG_RTL8723AE=y CONFIG_RTL8723BE=y CONFIG_RTL8188EE=y CONFIG_RTL8192CU=y CONFIG_RTLWIFI=y CONFIG_RTLWIFI_PCI=y CONFIG_RTLWIFI_USB=y CONFIG_RTLWIFI_DEBUG=y CONFIG_RTL8192C_COMMON=y CONFIG_RTL8723_COMMON=y CONFIG_RTLBTCOEXIST=y CONFIG_WL_TI=y CONFIG_WL1251=y CONFIG_WL1251_SPI=y CONFIG_WL1251_SDIO=y CONFIG_WL12XX=y CONFIG_WL18XX=y CONFIG_WLCORE=y CONFIG_WLCORE_SPI=y CONFIG_WLCORE_SDIO=y CONFIG_WILINK_PLATFORM_DATA=y CONFIG_ZD1211RW=y CONFIG_ZD1211RW_DEBUG=y CONFIG_MWIFIEX=y CONFIG_MWIFIEX_SDIO=y CONFIG_MWIFIEX_PCIE=y CONFIG_MWIFIEX_USB=y CONFIG_CW1200=y CONFIG_CW1200_WLAN_SDIO=y CONFIG_CW1200_WLAN_SPI=y CONFIG_RSI_91X=y CONFIG_RSI_DEBUGFS=y CONFIG_RSI_SDIO=y CONFIG_RSI_USB=y # # WiMAX Wireless Broadband devices # CONFIG_WIMAX_I2400M=y CONFIG_WIMAX_I2400M_USB=y CONFIG_WIMAX_I2400M_DEBUG_LEVEL=8 CONFIG_WAN=y CONFIG_LANMEDIA=y CONFIG_HDLC=y CONFIG_HDLC_RAW=y CONFIG_HDLC_RAW_ETH=y CONFIG_HDLC_CISCO=y CONFIG_HDLC_FR=y CONFIG_HDLC_PPP=y CONFIG_HDLC_X25=y CONFIG_PCI200SYN=y CONFIG_WANXL=y CONFIG_PC300TOO=y CONFIG_FARSYNC=y # CONFIG_DSCC4 is not set CONFIG_DLCI=y CONFIG_DLCI_MAX=8 CONFIG_LAPBETHER=y CONFIG_X25_ASY=y CONFIG_SBNI=y CONFIG_SBNI_MULTILINE=y CONFIG_IEEE802154_DRIVERS=y CONFIG_IEEE802154_FAKEHARD=y CONFIG_IEEE802154_FAKELB=y CONFIG_IEEE802154_AT86RF230=y CONFIG_IEEE802154_MRF24J40=y CONFIG_IEEE802154_CC2520=y CONFIG_XEN_NETDEV_FRONTEND=y CONFIG_XEN_NETDEV_BACKEND=y CONFIG_VMXNET3=y CONFIG_HYPERV_NET=y CONFIG_ISDN=y CONFIG_ISDN_I4L=y CONFIG_ISDN_PPP=y CONFIG_ISDN_PPP_VJ=y CONFIG_ISDN_MPP=y CONFIG_IPPP_FILTER=y CONFIG_ISDN_PPP_BSDCOMP=y CONFIG_ISDN_AUDIO=y CONFIG_ISDN_TTY_FAX=y CONFIG_ISDN_X25=y # # ISDN feature submodules # CONFIG_ISDN_DIVERSION=y # # ISDN4Linux hardware drivers # # # Passive cards # CONFIG_ISDN_DRV_HISAX=y # # D-channel protocol features # CONFIG_HISAX_EURO=y CONFIG_DE_AOC=y # CONFIG_HISAX_NO_SENDCOMPLETE is not set # CONFIG_HISAX_NO_LLC is not set # CONFIG_HISAX_NO_KEYPAD is not set CONFIG_HISAX_1TR6=y CONFIG_HISAX_NI1=y CONFIG_HISAX_MAX_CARDS=8 # # HiSax supported cards # CONFIG_HISAX_16_3=y CONFIG_HISAX_TELESPCI=y CONFIG_HISAX_S0BOX=y CONFIG_HISAX_FRITZPCI=y CONFIG_HISAX_AVM_A1_PCMCIA=y CONFIG_HISAX_ELSA=y CONFIG_HISAX_DIEHLDIVA=y CONFIG_HISAX_SEDLBAUER=y CONFIG_HISAX_NETJET=y CONFIG_HISAX_NETJET_U=y CONFIG_HISAX_NICCY=y CONFIG_HISAX_BKM_A4T=y CONFIG_HISAX_SCT_QUADRO=y CONFIG_HISAX_GAZEL=y CONFIG_HISAX_HFC_PCI=y CONFIG_HISAX_W6692=y CONFIG_HISAX_HFC_SX=y CONFIG_HISAX_ENTERNOW_PCI=y CONFIG_HISAX_DEBUG=y # # HiSax PCMCIA card service modules # CONFIG_HISAX_SEDLBAUER_CS=y CONFIG_HISAX_ELSA_CS=y CONFIG_HISAX_AVM_A1_CS=y CONFIG_HISAX_TELES_CS=y # # HiSax sub driver modules # CONFIG_HISAX_ST5481=y CONFIG_HISAX_HFCUSB=y CONFIG_HISAX_HFC4S8S=y CONFIG_HISAX_FRITZ_PCIPNP=y # # Active cards # CONFIG_ISDN_CAPI=y CONFIG_CAPI_TRACE=y CONFIG_ISDN_CAPI_CAPI20=y CONFIG_ISDN_CAPI_MIDDLEWARE=y CONFIG_ISDN_CAPI_CAPIDRV=y CONFIG_ISDN_CAPI_CAPIDRV_VERBOSE=y # # CAPI hardware drivers # CONFIG_CAPI_AVM=y CONFIG_ISDN_DRV_AVMB1_B1PCI=y CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=y CONFIG_ISDN_DRV_AVMB1_AVM_CS=y CONFIG_ISDN_DRV_AVMB1_T1PCI=y CONFIG_ISDN_DRV_AVMB1_C4=y CONFIG_CAPI_EICON=y CONFIG_ISDN_DIVAS=y CONFIG_ISDN_DIVAS_BRIPCI=y CONFIG_ISDN_DIVAS_PRIPCI=y CONFIG_ISDN_DIVAS_DIVACAPI=y CONFIG_ISDN_DIVAS_USERIDI=y # CONFIG_ISDN_DIVAS_MAINT is not set CONFIG_ISDN_DRV_GIGASET=y CONFIG_GIGASET_CAPI=y # CONFIG_GIGASET_I4L is not set # CONFIG_GIGASET_DUMMYLL is not set CONFIG_GIGASET_BASE=y CONFIG_GIGASET_M105=y CONFIG_GIGASET_M101=y CONFIG_GIGASET_DEBUG=y # CONFIG_HYSDN is not set CONFIG_MISDN=y CONFIG_MISDN_DSP=y CONFIG_MISDN_L1OIP=y # # mISDN hardware drivers # CONFIG_MISDN_HFCPCI=y CONFIG_MISDN_HFCMULTI=y CONFIG_MISDN_HFCUSB=y CONFIG_MISDN_AVMFRITZ=y CONFIG_MISDN_SPEEDFAX=y CONFIG_MISDN_INFINEON=y CONFIG_MISDN_W6692=y CONFIG_MISDN_NETJET=y CONFIG_MISDN_IPAC=y CONFIG_MISDN_ISAR=y CONFIG_ISDN_HDLC=y # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=y CONFIG_INPUT_POLLDEV=y CONFIG_INPUT_SPARSEKMAP=y CONFIG_INPUT_MATRIXKMAP=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y CONFIG_INPUT_EVBUG=y # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ADP5520=y CONFIG_KEYBOARD_ADP5588=y CONFIG_KEYBOARD_ADP5589=y CONFIG_KEYBOARD_ATKBD=y CONFIG_KEYBOARD_QT1070=y CONFIG_KEYBOARD_QT2160=y CONFIG_KEYBOARD_LKKBD=y CONFIG_KEYBOARD_GPIO=y CONFIG_KEYBOARD_GPIO_POLLED=y CONFIG_KEYBOARD_TCA6416=y CONFIG_KEYBOARD_TCA8418=y CONFIG_KEYBOARD_MATRIX=y CONFIG_KEYBOARD_LM8323=y CONFIG_KEYBOARD_LM8333=y CONFIG_KEYBOARD_MAX7359=y CONFIG_KEYBOARD_MCS=y CONFIG_KEYBOARD_MPR121=y CONFIG_KEYBOARD_NEWTON=y CONFIG_KEYBOARD_OPENCORES=y CONFIG_KEYBOARD_SAMSUNG=y CONFIG_KEYBOARD_STOWAWAY=y CONFIG_KEYBOARD_SUNKBD=y CONFIG_KEYBOARD_TC3589X=y CONFIG_KEYBOARD_TWL4030=y CONFIG_KEYBOARD_XTKBD=y CONFIG_KEYBOARD_CROS_EC=y CONFIG_INPUT_LEDS=y CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_CYPRESS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y CONFIG_MOUSE_PS2_ELANTECH=y CONFIG_MOUSE_PS2_SENTELIC=y CONFIG_MOUSE_PS2_TOUCHKIT=y CONFIG_MOUSE_SERIAL=y CONFIG_MOUSE_APPLETOUCH=y CONFIG_MOUSE_BCM5974=y CONFIG_MOUSE_CYAPA=y CONFIG_MOUSE_VSXXXAA=y CONFIG_MOUSE_GPIO=y CONFIG_MOUSE_SYNAPTICS_I2C=y CONFIG_MOUSE_SYNAPTICS_USB=y CONFIG_INPUT_JOYSTICK=y CONFIG_JOYSTICK_ANALOG=y CONFIG_JOYSTICK_A3D=y CONFIG_JOYSTICK_ADI=y CONFIG_JOYSTICK_COBRA=y CONFIG_JOYSTICK_GF2K=y CONFIG_JOYSTICK_GRIP=y CONFIG_JOYSTICK_GRIP_MP=y CONFIG_JOYSTICK_GUILLEMOT=y CONFIG_JOYSTICK_INTERACT=y CONFIG_JOYSTICK_SIDEWINDER=y CONFIG_JOYSTICK_TMDC=y CONFIG_JOYSTICK_IFORCE=y CONFIG_JOYSTICK_IFORCE_USB=y CONFIG_JOYSTICK_IFORCE_232=y CONFIG_JOYSTICK_WARRIOR=y CONFIG_JOYSTICK_MAGELLAN=y CONFIG_JOYSTICK_SPACEORB=y CONFIG_JOYSTICK_SPACEBALL=y CONFIG_JOYSTICK_STINGER=y CONFIG_JOYSTICK_TWIDJOY=y CONFIG_JOYSTICK_ZHENHUA=y CONFIG_JOYSTICK_AS5011=y CONFIG_JOYSTICK_JOYDUMP=y CONFIG_JOYSTICK_XPAD=y CONFIG_JOYSTICK_XPAD_FF=y CONFIG_JOYSTICK_XPAD_LEDS=y CONFIG_INPUT_TABLET=y CONFIG_TABLET_USB_ACECAD=y CONFIG_TABLET_USB_AIPTEK=y CONFIG_TABLET_USB_GTCO=y CONFIG_TABLET_USB_HANWANG=y CONFIG_TABLET_USB_KBTAB=y CONFIG_TABLET_SERIAL_WACOM4=y CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_88PM860X=y CONFIG_TOUCHSCREEN_ADS7846=y CONFIG_TOUCHSCREEN_AD7877=y CONFIG_TOUCHSCREEN_AD7879=y CONFIG_TOUCHSCREEN_AD7879_I2C=y CONFIG_TOUCHSCREEN_AD7879_SPI=y CONFIG_TOUCHSCREEN_ATMEL_MXT=y CONFIG_TOUCHSCREEN_AUO_PIXCIR=y CONFIG_TOUCHSCREEN_BU21013=y CONFIG_TOUCHSCREEN_CY8CTMG110=y CONFIG_TOUCHSCREEN_CYTTSP_CORE=y CONFIG_TOUCHSCREEN_CYTTSP_I2C=y CONFIG_TOUCHSCREEN_CYTTSP_SPI=y CONFIG_TOUCHSCREEN_CYTTSP4_CORE=y CONFIG_TOUCHSCREEN_CYTTSP4_I2C=y CONFIG_TOUCHSCREEN_CYTTSP4_SPI=y CONFIG_TOUCHSCREEN_DA9034=y CONFIG_TOUCHSCREEN_DA9052=y CONFIG_TOUCHSCREEN_DYNAPRO=y CONFIG_TOUCHSCREEN_HAMPSHIRE=y CONFIG_TOUCHSCREEN_EETI=y CONFIG_TOUCHSCREEN_FUJITSU=y CONFIG_TOUCHSCREEN_ILI210X=y CONFIG_TOUCHSCREEN_GUNZE=y CONFIG_TOUCHSCREEN_ELO=y CONFIG_TOUCHSCREEN_WACOM_W8001=y CONFIG_TOUCHSCREEN_WACOM_I2C=y CONFIG_TOUCHSCREEN_MAX11801=y CONFIG_TOUCHSCREEN_MCS5000=y CONFIG_TOUCHSCREEN_MMS114=y CONFIG_TOUCHSCREEN_MTOUCH=y CONFIG_TOUCHSCREEN_INEXIO=y CONFIG_TOUCHSCREEN_MK712=y CONFIG_TOUCHSCREEN_PENMOUNT=y CONFIG_TOUCHSCREEN_EDT_FT5X06=y CONFIG_TOUCHSCREEN_TOUCHRIGHT=y CONFIG_TOUCHSCREEN_TOUCHWIN=y CONFIG_TOUCHSCREEN_TI_AM335X_TSC=y CONFIG_TOUCHSCREEN_PIXCIR=y CONFIG_TOUCHSCREEN_WM831X=y CONFIG_TOUCHSCREEN_USB_COMPOSITE=y CONFIG_TOUCHSCREEN_MC13783=y CONFIG_TOUCHSCREEN_USB_EGALAX=y CONFIG_TOUCHSCREEN_USB_PANJIT=y CONFIG_TOUCHSCREEN_USB_3M=y CONFIG_TOUCHSCREEN_USB_ITM=y CONFIG_TOUCHSCREEN_USB_ETURBO=y CONFIG_TOUCHSCREEN_USB_GUNZE=y CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y CONFIG_TOUCHSCREEN_USB_IRTOUCH=y CONFIG_TOUCHSCREEN_USB_IDEALTEK=y CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y CONFIG_TOUCHSCREEN_USB_GOTOP=y CONFIG_TOUCHSCREEN_USB_JASTEC=y CONFIG_TOUCHSCREEN_USB_ELO=y CONFIG_TOUCHSCREEN_USB_E2I=y CONFIG_TOUCHSCREEN_USB_ZYTRONIC=y CONFIG_TOUCHSCREEN_USB_ETT_TC45USB=y CONFIG_TOUCHSCREEN_USB_NEXIO=y CONFIG_TOUCHSCREEN_USB_EASYTOUCH=y CONFIG_TOUCHSCREEN_TOUCHIT213=y CONFIG_TOUCHSCREEN_TSC_SERIO=y CONFIG_TOUCHSCREEN_TSC2005=y CONFIG_TOUCHSCREEN_TSC2007=y CONFIG_TOUCHSCREEN_PCAP=y CONFIG_TOUCHSCREEN_ST1232=y CONFIG_TOUCHSCREEN_SUR40=y CONFIG_TOUCHSCREEN_TPS6507X=y CONFIG_TOUCHSCREEN_ZFORCE=y CONFIG_INPUT_MISC=y CONFIG_INPUT_88PM860X_ONKEY=y CONFIG_INPUT_88PM80X_ONKEY=y CONFIG_INPUT_AD714X=y CONFIG_INPUT_AD714X_I2C=y CONFIG_INPUT_AD714X_SPI=y CONFIG_INPUT_BMA150=y CONFIG_INPUT_PCSPKR=y CONFIG_INPUT_MAX8925_ONKEY=y CONFIG_INPUT_MAX8997_HAPTIC=y CONFIG_INPUT_MC13783_PWRBUTTON=y CONFIG_INPUT_MMA8450=y CONFIG_INPUT_MPU3050=y CONFIG_INPUT_APANEL=y CONFIG_INPUT_GP2A=y CONFIG_INPUT_GPIO_BEEPER=y CONFIG_INPUT_GPIO_TILT_POLLED=y CONFIG_INPUT_ATLAS_BTNS=y CONFIG_INPUT_ATI_REMOTE2=y CONFIG_INPUT_KEYSPAN_REMOTE=y CONFIG_INPUT_KXTJ9=y CONFIG_INPUT_KXTJ9_POLLED_MODE=y CONFIG_INPUT_POWERMATE=y CONFIG_INPUT_YEALINK=y CONFIG_INPUT_CM109=y CONFIG_INPUT_RETU_PWRBUTTON=y CONFIG_INPUT_TWL4030_PWRBUTTON=y CONFIG_INPUT_TWL4030_VIBRA=y CONFIG_INPUT_TWL6040_VIBRA=y CONFIG_INPUT_UINPUT=y CONFIG_INPUT_PCF50633_PMU=y CONFIG_INPUT_PCF8574=y CONFIG_INPUT_PWM_BEEPER=y CONFIG_INPUT_GPIO_ROTARY_ENCODER=y CONFIG_INPUT_DA9052_ONKEY=y CONFIG_INPUT_DA9055_ONKEY=y CONFIG_INPUT_WM831X_ON=y CONFIG_INPUT_PCAP=y CONFIG_INPUT_ADXL34X=y CONFIG_INPUT_ADXL34X_I2C=y CONFIG_INPUT_ADXL34X_SPI=y CONFIG_INPUT_IMS_PCU=y CONFIG_INPUT_CMA3000=y CONFIG_INPUT_CMA3000_I2C=y CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y CONFIG_INPUT_IDEAPAD_SLIDEBAR=y # CONFIG_INPUT_SOC_BUTTON_ARRAY is not set CONFIG_INPUT_DRV260X_HAPTICS=y # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y CONFIG_SERIO_CT82C710=y CONFIG_SERIO_PCIPS2=y CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=y CONFIG_SERIO_ALTERA_PS2=y CONFIG_SERIO_PS2MULT=y CONFIG_SERIO_ARC_PS2=y CONFIG_HYPERV_KEYBOARD=y CONFIG_GAMEPORT=y CONFIG_GAMEPORT_NS558=y CONFIG_GAMEPORT_L4=y CONFIG_GAMEPORT_EMU10K1=y CONFIG_GAMEPORT_FM801=y # # Character devices # CONFIG_TTY=y CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_VT_CONSOLE_SLEEP=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_UNIX98_PTYS=y CONFIG_DEVPTS_MULTIPLE_INSTANCES=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 CONFIG_SERIAL_NONSTANDARD=y CONFIG_ROCKETPORT=y CONFIG_CYCLADES=y CONFIG_CYZ_INTR=y CONFIG_MOXA_INTELLIO=y CONFIG_MOXA_SMARTIO=y CONFIG_SYNCLINK=y CONFIG_SYNCLINKMP=y CONFIG_SYNCLINK_GT=y CONFIG_NOZOMI=y CONFIG_ISI=y CONFIG_N_HDLC=y CONFIG_N_GSM=y CONFIG_TRACE_ROUTER=y CONFIG_TRACE_SINK=y CONFIG_DEVKMEM=y # # Serial drivers # CONFIG_SERIAL_EARLYCON=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DMA=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_CS=y CONFIG_SERIAL_8250_NR_UARTS=32 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y CONFIG_SERIAL_8250_DW=y # # Non-8250 serial port support # CONFIG_SERIAL_MAX3100=y CONFIG_SERIAL_MAX310X=y CONFIG_SERIAL_MRST_MAX3110=y CONFIG_SERIAL_MFD_HSU=y CONFIG_SERIAL_MFD_HSU_CONSOLE=y CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_SERIAL_JSM=y CONFIG_SERIAL_SCCNXP=y CONFIG_SERIAL_SCCNXP_CONSOLE=y CONFIG_SERIAL_SC16IS7XX=y CONFIG_SERIAL_ALTERA_JTAGUART=y CONFIG_SERIAL_ALTERA_JTAGUART_CONSOLE=y CONFIG_SERIAL_ALTERA_JTAGUART_CONSOLE_BYPASS=y CONFIG_SERIAL_ALTERA_UART=y CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4 CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200 CONFIG_SERIAL_ALTERA_UART_CONSOLE=y CONFIG_SERIAL_IFX6X60=y CONFIG_SERIAL_ARC=y CONFIG_SERIAL_ARC_CONSOLE=y CONFIG_SERIAL_ARC_NR_PORTS=1 CONFIG_SERIAL_RP2=y CONFIG_SERIAL_RP2_NR_UARTS=32 CONFIG_SERIAL_FSL_LPUART=y CONFIG_SERIAL_FSL_LPUART_CONSOLE=y CONFIG_SERIAL_MEN_Z135=y CONFIG_TTY_PRINTK=y CONFIG_HVC_DRIVER=y CONFIG_HVC_IRQ=y CONFIG_HVC_XEN=y CONFIG_HVC_XEN_FRONTEND=y CONFIG_VIRTIO_CONSOLE=y # CONFIG_IPMI_HANDLER is not set CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_TIMERIOMEM=y CONFIG_HW_RANDOM_INTEL=y CONFIG_HW_RANDOM_AMD=y CONFIG_HW_RANDOM_VIA=y CONFIG_HW_RANDOM_VIRTIO=y CONFIG_HW_RANDOM_TPM=y CONFIG_NVRAM=y CONFIG_R3964=y CONFIG_APPLICOM=y # # PCMCIA character devices # CONFIG_SYNCLINK_CS=y CONFIG_CARDMAN_4000=y CONFIG_CARDMAN_4040=y CONFIG_IPWIRELESS=y CONFIG_MWAVE=y CONFIG_RAW_DRIVER=y CONFIG_MAX_RAW_DEVS=256 CONFIG_HPET=y CONFIG_HPET_MMAP=y CONFIG_HPET_MMAP_DEFAULT=y CONFIG_HANGCHECK_TIMER=y CONFIG_UV_MMTIMER=y CONFIG_TCG_TPM=y CONFIG_TCG_TIS=y CONFIG_TCG_TIS_I2C_ATMEL=y CONFIG_TCG_TIS_I2C_INFINEON=y CONFIG_TCG_TIS_I2C_NUVOTON=y CONFIG_TCG_NSC=y CONFIG_TCG_ATMEL=y CONFIG_TCG_INFINEON=y CONFIG_TCG_ST33_I2C=y CONFIG_TCG_XEN=y CONFIG_TELCLOCK=y CONFIG_DEVPORT=y # # I2C support # CONFIG_I2C=y CONFIG_ACPI_I2C_OPREGION=y CONFIG_I2C_BOARDINFO=y CONFIG_I2C_COMPAT=y CONFIG_I2C_CHARDEV=y CONFIG_I2C_MUX=y # # Multiplexer I2C Chip support # CONFIG_I2C_MUX_GPIO=y CONFIG_I2C_MUX_PCA9541=y CONFIG_I2C_MUX_PCA954x=y CONFIG_I2C_MUX_PINCTRL=y CONFIG_I2C_HELPER_AUTO=y CONFIG_I2C_SMBUS=y CONFIG_I2C_ALGOBIT=y CONFIG_I2C_ALGOPCA=y # # I2C Hardware Bus support # # # PC SMBus host controller drivers # CONFIG_I2C_ALI1535=y CONFIG_I2C_ALI1563=y CONFIG_I2C_ALI15X3=y CONFIG_I2C_AMD756=y CONFIG_I2C_AMD756_S4882=y CONFIG_I2C_AMD8111=y CONFIG_I2C_I801=y CONFIG_I2C_ISCH=y CONFIG_I2C_ISMT=y CONFIG_I2C_PIIX4=y CONFIG_I2C_NFORCE2=y CONFIG_I2C_NFORCE2_S4985=y CONFIG_I2C_SIS5595=y CONFIG_I2C_SIS630=y CONFIG_I2C_SIS96X=y CONFIG_I2C_VIA=y CONFIG_I2C_VIAPRO=y # # ACPI drivers # CONFIG_I2C_SCMI=y # # I2C system bus drivers (mostly embedded / system-on-chip) # CONFIG_I2C_CBUS_GPIO=y CONFIG_I2C_DESIGNWARE_CORE=y CONFIG_I2C_DESIGNWARE_PLATFORM=y CONFIG_I2C_DESIGNWARE_PCI=y CONFIG_I2C_GPIO=y CONFIG_I2C_KEMPLD=y CONFIG_I2C_OCORES=y CONFIG_I2C_PCA_PLATFORM=y # CONFIG_I2C_PXA_PCI is not set CONFIG_I2C_SIMTEC=y CONFIG_I2C_XILINX=y # # External I2C/SMBus adapter drivers # CONFIG_I2C_DIOLAN_U2C=y CONFIG_I2C_PARPORT_LIGHT=y CONFIG_I2C_ROBOTFUZZ_OSIF=y CONFIG_I2C_TAOS_EVM=y CONFIG_I2C_TINY_USB=y CONFIG_I2C_VIPERBOARD=y # # Other I2C/SMBus bus drivers # CONFIG_I2C_CROS_EC_TUNNEL=y # CONFIG_I2C_STUB is not set CONFIG_I2C_DEBUG_CORE=y CONFIG_I2C_DEBUG_ALGO=y CONFIG_I2C_DEBUG_BUS=y CONFIG_SPI=y CONFIG_SPI_DEBUG=y CONFIG_SPI_MASTER=y # # SPI Master Controller Drivers # CONFIG_SPI_ALTERA=y CONFIG_SPI_BITBANG=y CONFIG_SPI_GPIO=y CONFIG_SPI_OC_TINY=y CONFIG_SPI_PXA2XX_DMA=y CONFIG_SPI_PXA2XX=y CONFIG_SPI_PXA2XX_PCI=y CONFIG_SPI_SC18IS602=y CONFIG_SPI_XCOMM=y CONFIG_SPI_XILINX=y CONFIG_SPI_DESIGNWARE=y CONFIG_SPI_DW_PCI=y CONFIG_SPI_DW_MID_DMA=y CONFIG_SPI_DW_MMIO=y # # SPI Protocol Masters # CONFIG_SPI_SPIDEV=y CONFIG_SPI_TLE62X0=y CONFIG_SPMI=y CONFIG_HSI=y CONFIG_HSI_BOARDINFO=y # # HSI controllers # # # HSI clients # CONFIG_HSI_CHAR=y # # PPS support # CONFIG_PPS=y CONFIG_PPS_DEBUG=y # # PPS clients support # CONFIG_PPS_CLIENT_KTIMER=y CONFIG_PPS_CLIENT_LDISC=y CONFIG_PPS_CLIENT_GPIO=y # # PPS generators support # # # PTP clock support # CONFIG_PTP_1588_CLOCK=y CONFIG_DP83640_PHY=y CONFIG_PINCTRL=y # # Pin controllers # CONFIG_DEBUG_PINCTRL=y CONFIG_PINCTRL_BAYTRAIL=y CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_GPIOLIB=y CONFIG_GPIO_DEVRES=y CONFIG_GPIO_ACPI=y CONFIG_GPIOLIB_IRQCHIP=y CONFIG_DEBUG_GPIO=y CONFIG_GPIO_SYSFS=y CONFIG_GPIO_GENERIC=y CONFIG_GPIO_DA9052=y CONFIG_GPIO_DA9055=y CONFIG_GPIO_MAX730X=y # # Memory mapped GPIO drivers: # CONFIG_GPIO_GENERIC_PLATFORM=y CONFIG_GPIO_IT8761E=y CONFIG_GPIO_F7188X=y CONFIG_GPIO_SCH311X=y CONFIG_GPIO_SCH=y CONFIG_GPIO_ICH=y CONFIG_GPIO_VX855=y CONFIG_GPIO_LYNXPOINT=y # # I2C GPIO expanders: # CONFIG_GPIO_ARIZONA=y CONFIG_GPIO_CRYSTAL_COVE=y CONFIG_GPIO_LP3943=y CONFIG_GPIO_MAX7300=y CONFIG_GPIO_MAX732X=y CONFIG_GPIO_MAX732X_IRQ=y CONFIG_GPIO_PCA953X=y CONFIG_GPIO_PCA953X_IRQ=y CONFIG_GPIO_PCF857X=y CONFIG_GPIO_RC5T583=y CONFIG_GPIO_SX150X=y CONFIG_GPIO_TC3589X=y CONFIG_GPIO_TPS65912=y CONFIG_GPIO_TWL4030=y CONFIG_GPIO_TWL6040=y CONFIG_GPIO_WM831X=y CONFIG_GPIO_WM8350=y CONFIG_GPIO_WM8994=y CONFIG_GPIO_ADP5520=y CONFIG_GPIO_ADP5588=y CONFIG_GPIO_ADP5588_IRQ=y # # PCI GPIO expanders: # CONFIG_GPIO_AMD8111=y CONFIG_GPIO_INTEL_MID=y CONFIG_GPIO_ML_IOH=y CONFIG_GPIO_RDC321X=y # # SPI GPIO expanders: # CONFIG_GPIO_MAX7301=y CONFIG_GPIO_MCP23S08=y CONFIG_GPIO_MC33880=y # # AC97 GPIO expanders: # # # LPC GPIO expanders: # CONFIG_GPIO_KEMPLD=y # # MODULbus GPIO expanders: # CONFIG_GPIO_JANZ_TTL=y CONFIG_GPIO_PALMAS=y CONFIG_GPIO_TPS6586X=y CONFIG_GPIO_TPS65910=y # # USB GPIO expanders: # CONFIG_GPIO_VIPERBOARD=y CONFIG_W1=y CONFIG_W1_CON=y # # 1-wire Bus Masters # CONFIG_W1_MASTER_MATROX=y CONFIG_W1_MASTER_DS2490=y CONFIG_W1_MASTER_DS2482=y CONFIG_W1_MASTER_DS1WM=y CONFIG_W1_MASTER_GPIO=y # # 1-wire Slaves # CONFIG_W1_SLAVE_THERM=y CONFIG_W1_SLAVE_SMEM=y CONFIG_W1_SLAVE_DS2408=y CONFIG_W1_SLAVE_DS2408_READBACK=y CONFIG_W1_SLAVE_DS2413=y CONFIG_W1_SLAVE_DS2406=y CONFIG_W1_SLAVE_DS2423=y CONFIG_W1_SLAVE_DS2431=y CONFIG_W1_SLAVE_DS2433=y CONFIG_W1_SLAVE_DS2433_CRC=y CONFIG_W1_SLAVE_DS2760=y CONFIG_W1_SLAVE_DS2780=y CONFIG_W1_SLAVE_DS2781=y CONFIG_W1_SLAVE_DS28E04=y CONFIG_W1_SLAVE_BQ27000=y CONFIG_POWER_SUPPLY=y CONFIG_POWER_SUPPLY_DEBUG=y CONFIG_PDA_POWER=y CONFIG_GENERIC_ADC_BATTERY=y CONFIG_MAX8925_POWER=y CONFIG_WM831X_BACKUP=y CONFIG_WM831X_POWER=y CONFIG_WM8350_POWER=y CONFIG_TEST_POWER=y CONFIG_BATTERY_88PM860X=y CONFIG_BATTERY_DS2760=y CONFIG_BATTERY_DS2780=y CONFIG_BATTERY_DS2781=y CONFIG_BATTERY_DS2782=y CONFIG_BATTERY_SBS=y CONFIG_BATTERY_BQ27x00=y CONFIG_BATTERY_BQ27X00_I2C=y CONFIG_BATTERY_BQ27X00_PLATFORM=y CONFIG_BATTERY_DA9030=y CONFIG_BATTERY_DA9052=y CONFIG_BATTERY_MAX17040=y CONFIG_BATTERY_MAX17042=y CONFIG_BATTERY_TWL4030_MADC=y CONFIG_CHARGER_88PM860X=y CONFIG_CHARGER_PCF50633=y CONFIG_BATTERY_RX51=y CONFIG_CHARGER_ISP1704=y CONFIG_CHARGER_MAX8903=y CONFIG_CHARGER_TWL4030=y CONFIG_CHARGER_LP8727=y CONFIG_CHARGER_LP8788=y CONFIG_CHARGER_GPIO=y CONFIG_CHARGER_MANAGER=y CONFIG_CHARGER_MAX14577=y # CONFIG_CHARGER_MAX8997 is not set # CONFIG_CHARGER_MAX8998 is not set CONFIG_CHARGER_BQ2415X=y CONFIG_CHARGER_BQ24190=y CONFIG_CHARGER_BQ24735=y CONFIG_CHARGER_SMB347=y CONFIG_CHARGER_TPS65090=y CONFIG_POWER_RESET=y CONFIG_POWER_AVS=y CONFIG_HWMON=y CONFIG_HWMON_VID=y CONFIG_HWMON_DEBUG_CHIP=y # # Native drivers # CONFIG_SENSORS_ABITUGURU=y CONFIG_SENSORS_ABITUGURU3=y CONFIG_SENSORS_AD7314=y CONFIG_SENSORS_AD7414=y CONFIG_SENSORS_AD7418=y CONFIG_SENSORS_ADM1021=y CONFIG_SENSORS_ADM1025=y CONFIG_SENSORS_ADM1026=y CONFIG_SENSORS_ADM1029=y CONFIG_SENSORS_ADM1031=y CONFIG_SENSORS_ADM9240=y CONFIG_SENSORS_ADT7X10=y CONFIG_SENSORS_ADT7310=y CONFIG_SENSORS_ADT7410=y CONFIG_SENSORS_ADT7411=y CONFIG_SENSORS_ADT7462=y CONFIG_SENSORS_ADT7470=y CONFIG_SENSORS_ADT7475=y CONFIG_SENSORS_ASC7621=y CONFIG_SENSORS_K8TEMP=y CONFIG_SENSORS_K10TEMP=y CONFIG_SENSORS_FAM15H_POWER=y CONFIG_SENSORS_APPLESMC=y CONFIG_SENSORS_ASB100=y CONFIG_SENSORS_ATXP1=y CONFIG_SENSORS_DS620=y CONFIG_SENSORS_DS1621=y CONFIG_SENSORS_DA9052_ADC=y CONFIG_SENSORS_DA9055=y CONFIG_SENSORS_I5K_AMB=y CONFIG_SENSORS_F71805F=y CONFIG_SENSORS_F71882FG=y CONFIG_SENSORS_F75375S=y CONFIG_SENSORS_MC13783_ADC=y CONFIG_SENSORS_FSCHMD=y CONFIG_SENSORS_GL518SM=y CONFIG_SENSORS_GL520SM=y CONFIG_SENSORS_G760A=y # CONFIG_SENSORS_G762 is not set CONFIG_SENSORS_GPIO_FAN=y CONFIG_SENSORS_HIH6130=y CONFIG_SENSORS_IIO_HWMON=y CONFIG_SENSORS_CORETEMP=y CONFIG_SENSORS_IT87=y CONFIG_SENSORS_JC42=y CONFIG_SENSORS_POWR1220=y CONFIG_SENSORS_LINEAGE=y CONFIG_SENSORS_LTC2945=y CONFIG_SENSORS_LTC4151=y CONFIG_SENSORS_LTC4215=y CONFIG_SENSORS_LTC4222=y CONFIG_SENSORS_LTC4245=y CONFIG_SENSORS_LTC4260=y CONFIG_SENSORS_LTC4261=y CONFIG_SENSORS_MAX1111=y CONFIG_SENSORS_MAX16065=y CONFIG_SENSORS_MAX1619=y CONFIG_SENSORS_MAX1668=y CONFIG_SENSORS_MAX197=y CONFIG_SENSORS_MAX6639=y CONFIG_SENSORS_MAX6642=y CONFIG_SENSORS_MAX6650=y CONFIG_SENSORS_MAX6697=y CONFIG_SENSORS_HTU21=y CONFIG_SENSORS_MCP3021=y CONFIG_SENSORS_ADCXX=y CONFIG_SENSORS_LM63=y CONFIG_SENSORS_LM70=y CONFIG_SENSORS_LM73=y CONFIG_SENSORS_LM75=y CONFIG_SENSORS_LM77=y CONFIG_SENSORS_LM78=y CONFIG_SENSORS_LM80=y CONFIG_SENSORS_LM83=y CONFIG_SENSORS_LM85=y CONFIG_SENSORS_LM87=y CONFIG_SENSORS_LM90=y CONFIG_SENSORS_LM92=y CONFIG_SENSORS_LM93=y CONFIG_SENSORS_LM95234=y CONFIG_SENSORS_LM95241=y CONFIG_SENSORS_LM95245=y CONFIG_SENSORS_PC87360=y CONFIG_SENSORS_PC87427=y CONFIG_SENSORS_NTC_THERMISTOR=y CONFIG_SENSORS_NCT6683=y CONFIG_SENSORS_NCT6775=y CONFIG_SENSORS_PCF8591=y CONFIG_PMBUS=y CONFIG_SENSORS_PMBUS=y CONFIG_SENSORS_ADM1275=y CONFIG_SENSORS_LM25066=y CONFIG_SENSORS_LTC2978=y CONFIG_SENSORS_MAX16064=y CONFIG_SENSORS_MAX34440=y CONFIG_SENSORS_MAX8688=y CONFIG_SENSORS_TPS40422=y CONFIG_SENSORS_UCD9000=y CONFIG_SENSORS_UCD9200=y CONFIG_SENSORS_ZL6100=y CONFIG_SENSORS_SHT15=y CONFIG_SENSORS_SHT21=y CONFIG_SENSORS_SHTC1=y CONFIG_SENSORS_SIS5595=y CONFIG_SENSORS_DME1737=y CONFIG_SENSORS_EMC1403=y CONFIG_SENSORS_EMC2103=y CONFIG_SENSORS_EMC6W201=y CONFIG_SENSORS_SMSC47M1=y CONFIG_SENSORS_SMSC47M192=y CONFIG_SENSORS_SMSC47B397=y CONFIG_SENSORS_SCH56XX_COMMON=y CONFIG_SENSORS_SCH5627=y CONFIG_SENSORS_SCH5636=y CONFIG_SENSORS_SMM665=y CONFIG_SENSORS_ADC128D818=y CONFIG_SENSORS_ADS1015=y CONFIG_SENSORS_ADS7828=y CONFIG_SENSORS_ADS7871=y CONFIG_SENSORS_AMC6821=y CONFIG_SENSORS_INA209=y CONFIG_SENSORS_INA2XX=y CONFIG_SENSORS_THMC50=y CONFIG_SENSORS_TMP102=y CONFIG_SENSORS_TMP103=y CONFIG_SENSORS_TMP401=y CONFIG_SENSORS_TMP421=y CONFIG_SENSORS_TWL4030_MADC=y CONFIG_SENSORS_VIA_CPUTEMP=y CONFIG_SENSORS_VIA686A=y CONFIG_SENSORS_VT1211=y CONFIG_SENSORS_VT8231=y CONFIG_SENSORS_W83781D=y CONFIG_SENSORS_W83791D=y CONFIG_SENSORS_W83792D=y CONFIG_SENSORS_W83793=y CONFIG_SENSORS_W83795=y CONFIG_SENSORS_W83795_FANCTRL=y CONFIG_SENSORS_W83L785TS=y CONFIG_SENSORS_W83L786NG=y CONFIG_SENSORS_W83627HF=y CONFIG_SENSORS_W83627EHF=y CONFIG_SENSORS_WM831X=y CONFIG_SENSORS_WM8350=y # # ACPI drivers # CONFIG_SENSORS_ACPI_POWER=y CONFIG_SENSORS_ATK0110=y CONFIG_THERMAL=y CONFIG_THERMAL_HWMON=y CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y # CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set # CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set CONFIG_THERMAL_GOV_FAIR_SHARE=y CONFIG_THERMAL_GOV_STEP_WISE=y CONFIG_THERMAL_GOV_USER_SPACE=y CONFIG_THERMAL_EMULATION=y CONFIG_INTEL_POWERCLAMP=y CONFIG_X86_PKG_TEMP_THERMAL=y CONFIG_ACPI_INT3403_THERMAL=y CONFIG_INTEL_SOC_DTS_THERMAL=m # # Texas Instruments thermal drivers # CONFIG_WATCHDOG=y CONFIG_WATCHDOG_CORE=y CONFIG_WATCHDOG_NOWAYOUT=y # # Watchdog Device Drivers # # CONFIG_SOFT_WATCHDOG is not set # CONFIG_DA9052_WATCHDOG is not set # CONFIG_DA9055_WATCHDOG is not set # CONFIG_WM831X_WATCHDOG is not set # CONFIG_WM8350_WATCHDOG is not set CONFIG_XILINX_WATCHDOG=y CONFIG_DW_WATCHDOG=y # CONFIG_TWL4030_WATCHDOG is not set # CONFIG_RETU_WATCHDOG is not set # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_ALIM1535_WDT is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_F71808E_WDT is not set # CONFIG_SP5100_TCO is not set # CONFIG_SBC_FITPC2_WATCHDOG is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_IBMASR is not set # CONFIG_WAFER_WDT is not set # CONFIG_I6300ESB_WDT is not set # CONFIG_IE6XX_WDT is not set # CONFIG_ITCO_WDT is not set # CONFIG_IT8712F_WDT is not set # CONFIG_IT87_WDT is not set # CONFIG_HP_WATCHDOG is not set CONFIG_KEMPLD_WDT=y # CONFIG_SC1200_WDT is not set # CONFIG_PC87413_WDT is not set # CONFIG_NV_TCO is not set # CONFIG_60XX_WDT is not set # CONFIG_CPU5_WDT is not set # CONFIG_SMSC_SCH311X_WDT is not set # CONFIG_SMSC37B787_WDT is not set # CONFIG_VIA_WDT is not set # CONFIG_W83627HF_WDT is not set # CONFIG_W83877F_WDT is not set # CONFIG_W83977F_WDT is not set # CONFIG_MACHZ_WDT is not set # CONFIG_SBC_EPX_C3_WATCHDOG is not set CONFIG_MEN_A21_WDT=y # CONFIG_XEN_WDT is not set # # PCI-based Watchdog Cards # # CONFIG_PCIPCWATCHDOG is not set # CONFIG_WDTPCI is not set # # USB-based Watchdog Cards # # CONFIG_USBPCWATCHDOG is not set CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # CONFIG_SSB=y CONFIG_SSB_SPROM=y CONFIG_SSB_BLOCKIO=y CONFIG_SSB_PCIHOST_POSSIBLE=y CONFIG_SSB_PCIHOST=y CONFIG_SSB_B43_PCI_BRIDGE=y CONFIG_SSB_PCMCIAHOST_POSSIBLE=y CONFIG_SSB_PCMCIAHOST=y CONFIG_SSB_SDIOHOST_POSSIBLE=y CONFIG_SSB_SDIOHOST=y # CONFIG_SSB_SILENT is not set CONFIG_SSB_DEBUG=y CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y CONFIG_SSB_DRIVER_PCICORE=y CONFIG_SSB_DRIVER_GPIO=y CONFIG_BCMA_POSSIBLE=y # # Broadcom specific AMBA # CONFIG_BCMA=y CONFIG_BCMA_BLOCKIO=y CONFIG_BCMA_HOST_PCI_POSSIBLE=y CONFIG_BCMA_HOST_PCI=y CONFIG_BCMA_HOST_SOC=y CONFIG_BCMA_DRIVER_GMAC_CMN=y CONFIG_BCMA_DRIVER_GPIO=y CONFIG_BCMA_DEBUG=y # # Multifunction device drivers # CONFIG_MFD_CORE=y CONFIG_MFD_AS3711=y CONFIG_PMIC_ADP5520=y CONFIG_MFD_AAT2870_CORE=y CONFIG_MFD_BCM590XX=y CONFIG_MFD_AXP20X=y CONFIG_MFD_CROS_EC=y CONFIG_MFD_CROS_EC_I2C=y CONFIG_PMIC_DA903X=y CONFIG_PMIC_DA9052=y CONFIG_MFD_DA9052_SPI=y CONFIG_MFD_DA9052_I2C=y CONFIG_MFD_DA9055=y CONFIG_MFD_DA9063=y CONFIG_MFD_MC13XXX=y CONFIG_MFD_MC13XXX_SPI=y CONFIG_MFD_MC13XXX_I2C=y CONFIG_HTC_PASIC3=y CONFIG_HTC_I2CPLD=y CONFIG_LPC_ICH=y CONFIG_LPC_SCH=y CONFIG_INTEL_SOC_PMIC=y CONFIG_MFD_JANZ_CMODIO=y CONFIG_MFD_KEMPLD=y CONFIG_MFD_88PM800=y CONFIG_MFD_88PM805=y CONFIG_MFD_88PM860X=y CONFIG_MFD_MAX14577=y CONFIG_MFD_MAX77686=y CONFIG_MFD_MAX77693=y CONFIG_MFD_MAX8907=y CONFIG_MFD_MAX8925=y CONFIG_MFD_MAX8997=y CONFIG_MFD_MAX8998=y CONFIG_EZX_PCAP=y CONFIG_MFD_VIPERBOARD=y CONFIG_MFD_RETU=y CONFIG_MFD_PCF50633=y CONFIG_PCF50633_ADC=y CONFIG_PCF50633_GPIO=y CONFIG_MFD_RDC321X=y CONFIG_MFD_RTSX_PCI=y CONFIG_MFD_RTSX_USB=y CONFIG_MFD_RC5T583=y CONFIG_MFD_RN5T618=y CONFIG_MFD_SEC_CORE=y CONFIG_MFD_SI476X_CORE=y CONFIG_MFD_SM501=y CONFIG_MFD_SM501_GPIO=y CONFIG_MFD_SMSC=y CONFIG_ABX500_CORE=y CONFIG_AB3100_CORE=y CONFIG_AB3100_OTP=y CONFIG_MFD_SYSCON=y CONFIG_MFD_TI_AM335X_TSCADC=y CONFIG_MFD_LP3943=y CONFIG_MFD_LP8788=y CONFIG_MFD_PALMAS=y CONFIG_TPS6105X=y # CONFIG_TPS65010 is not set CONFIG_TPS6507X=y CONFIG_MFD_TPS65090=y CONFIG_MFD_TPS65217=y CONFIG_MFD_TPS65218=y CONFIG_MFD_TPS6586X=y CONFIG_MFD_TPS65910=y CONFIG_MFD_TPS65912=y CONFIG_MFD_TPS65912_I2C=y CONFIG_MFD_TPS65912_SPI=y CONFIG_MFD_TPS80031=y CONFIG_TWL4030_CORE=y CONFIG_MFD_TWL4030_AUDIO=y CONFIG_TWL6040_CORE=y CONFIG_MFD_WL1273_CORE=y CONFIG_MFD_LM3533=y CONFIG_MFD_TC3589X=y # CONFIG_MFD_TMIO is not set CONFIG_MFD_VX855=y CONFIG_MFD_ARIZONA=y CONFIG_MFD_ARIZONA_I2C=y CONFIG_MFD_ARIZONA_SPI=y CONFIG_MFD_WM5102=y CONFIG_MFD_WM5110=y CONFIG_MFD_WM8997=y CONFIG_MFD_WM8400=y CONFIG_MFD_WM831X=y CONFIG_MFD_WM831X_I2C=y CONFIG_MFD_WM831X_SPI=y CONFIG_MFD_WM8350=y CONFIG_MFD_WM8350_I2C=y CONFIG_MFD_WM8994=y CONFIG_REGULATOR=y CONFIG_REGULATOR_DEBUG=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_VIRTUAL_CONSUMER=y CONFIG_REGULATOR_USERSPACE_CONSUMER=y CONFIG_REGULATOR_88PM800=y CONFIG_REGULATOR_88PM8607=y CONFIG_REGULATOR_ACT8865=y CONFIG_REGULATOR_AD5398=y CONFIG_REGULATOR_ANATOP=y CONFIG_REGULATOR_AAT2870=y CONFIG_REGULATOR_AB3100=y CONFIG_REGULATOR_AS3711=y CONFIG_REGULATOR_AXP20X=y CONFIG_REGULATOR_BCM590XX=y CONFIG_REGULATOR_DA903X=y CONFIG_REGULATOR_DA9052=y CONFIG_REGULATOR_DA9055=y CONFIG_REGULATOR_DA9063=y CONFIG_REGULATOR_DA9210=y CONFIG_REGULATOR_DA9211=y CONFIG_REGULATOR_FAN53555=y CONFIG_REGULATOR_GPIO=y CONFIG_REGULATOR_ISL9305=y CONFIG_REGULATOR_ISL6271A=y CONFIG_REGULATOR_LP3971=y CONFIG_REGULATOR_LP3972=y CONFIG_REGULATOR_LP872X=y CONFIG_REGULATOR_LP8755=y CONFIG_REGULATOR_LP8788=y CONFIG_REGULATOR_LTC3589=y CONFIG_REGULATOR_MAX14577=y CONFIG_REGULATOR_MAX1586=y CONFIG_REGULATOR_MAX8649=y CONFIG_REGULATOR_MAX8660=y CONFIG_REGULATOR_MAX8907=y CONFIG_REGULATOR_MAX8925=y CONFIG_REGULATOR_MAX8952=y CONFIG_REGULATOR_MAX8973=y CONFIG_REGULATOR_MAX8997=y CONFIG_REGULATOR_MAX8998=y CONFIG_REGULATOR_MAX77686=y CONFIG_REGULATOR_MAX77693=y CONFIG_REGULATOR_MAX77802=y CONFIG_REGULATOR_MC13XXX_CORE=y CONFIG_REGULATOR_MC13783=y CONFIG_REGULATOR_MC13892=y CONFIG_REGULATOR_PALMAS=y CONFIG_REGULATOR_PCAP=y # CONFIG_REGULATOR_PCF50633 is not set CONFIG_REGULATOR_PFUZE100=y CONFIG_REGULATOR_RC5T583=y CONFIG_REGULATOR_RN5T618=y CONFIG_REGULATOR_S2MPA01=y CONFIG_REGULATOR_S2MPS11=y CONFIG_REGULATOR_S5M8767=y CONFIG_REGULATOR_TPS51632=y CONFIG_REGULATOR_TPS6105X=y CONFIG_REGULATOR_TPS62360=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65090=y CONFIG_REGULATOR_TPS65217=y CONFIG_REGULATOR_TPS6524X=y CONFIG_REGULATOR_TPS6586X=y CONFIG_REGULATOR_TPS65910=y CONFIG_REGULATOR_TPS65912=y CONFIG_REGULATOR_TPS80031=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_WM831X=y CONFIG_REGULATOR_WM8350=y CONFIG_REGULATOR_WM8400=y CONFIG_REGULATOR_WM8994=y CONFIG_MEDIA_SUPPORT=y # # Multimedia core support # CONFIG_MEDIA_CAMERA_SUPPORT=y CONFIG_MEDIA_ANALOG_TV_SUPPORT=y CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y CONFIG_MEDIA_RADIO_SUPPORT=y CONFIG_MEDIA_SDR_SUPPORT=y CONFIG_MEDIA_RC_SUPPORT=y CONFIG_MEDIA_CONTROLLER=y CONFIG_VIDEO_DEV=y CONFIG_VIDEO_V4L2_SUBDEV_API=y CONFIG_VIDEO_V4L2=y CONFIG_VIDEO_ADV_DEBUG=y CONFIG_VIDEO_FIXED_MINOR_RANGES=y CONFIG_VIDEO_TUNER=y CONFIG_V4L2_MEM2MEM_DEV=y CONFIG_VIDEOBUF_GEN=y CONFIG_VIDEOBUF_DMA_SG=y CONFIG_VIDEOBUF_VMALLOC=y CONFIG_VIDEOBUF_DVB=y CONFIG_VIDEOBUF2_CORE=y CONFIG_VIDEOBUF2_MEMOPS=y CONFIG_VIDEOBUF2_DMA_CONTIG=y CONFIG_VIDEOBUF2_VMALLOC=y CONFIG_VIDEOBUF2_DMA_SG=y CONFIG_VIDEOBUF2_DVB=y CONFIG_DVB_CORE=y CONFIG_DVB_NET=y CONFIG_TTPCI_EEPROM=y CONFIG_DVB_MAX_ADAPTERS=8 CONFIG_DVB_DYNAMIC_MINORS=y # # Media drivers # CONFIG_RC_CORE=y CONFIG_RC_MAP=y CONFIG_RC_DECODERS=y # CONFIG_LIRC is not set CONFIG_IR_NEC_DECODER=y CONFIG_IR_RC5_DECODER=y CONFIG_IR_RC6_DECODER=y CONFIG_IR_JVC_DECODER=y CONFIG_IR_SONY_DECODER=y CONFIG_IR_SANYO_DECODER=y CONFIG_IR_SHARP_DECODER=y CONFIG_IR_MCE_KBD_DECODER=y CONFIG_IR_XMP_DECODER=y CONFIG_RC_DEVICES=y CONFIG_RC_ATI_REMOTE=y CONFIG_IR_ENE=y CONFIG_IR_IMON=y CONFIG_IR_MCEUSB=y CONFIG_IR_ITE_CIR=y CONFIG_IR_FINTEK=y CONFIG_IR_NUVOTON=y CONFIG_IR_REDRAT3=y CONFIG_IR_STREAMZAP=y CONFIG_IR_WINBOND_CIR=y CONFIG_IR_IGUANA=y CONFIG_IR_TTUSBIR=y CONFIG_IR_IMG=y CONFIG_IR_IMG_RAW=y CONFIG_IR_IMG_HW=y CONFIG_IR_IMG_NEC=y CONFIG_IR_IMG_JVC=y CONFIG_IR_IMG_SONY=y CONFIG_IR_IMG_SHARP=y CONFIG_IR_IMG_SANYO=y CONFIG_RC_LOOPBACK=y CONFIG_IR_GPIO_CIR=y CONFIG_MEDIA_USB_SUPPORT=y # # Webcam devices # CONFIG_USB_VIDEO_CLASS=y CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y CONFIG_USB_GSPCA=y CONFIG_USB_M5602=y CONFIG_USB_STV06XX=y CONFIG_USB_GL860=y CONFIG_USB_GSPCA_BENQ=y CONFIG_USB_GSPCA_CONEX=y CONFIG_USB_GSPCA_CPIA1=y CONFIG_USB_GSPCA_DTCS033=y CONFIG_USB_GSPCA_ETOMS=y CONFIG_USB_GSPCA_FINEPIX=y CONFIG_USB_GSPCA_JEILINJ=y CONFIG_USB_GSPCA_JL2005BCD=y CONFIG_USB_GSPCA_KINECT=y CONFIG_USB_GSPCA_KONICA=y CONFIG_USB_GSPCA_MARS=y CONFIG_USB_GSPCA_MR97310A=y CONFIG_USB_GSPCA_NW80X=y CONFIG_USB_GSPCA_OV519=y CONFIG_USB_GSPCA_OV534=y CONFIG_USB_GSPCA_OV534_9=y CONFIG_USB_GSPCA_PAC207=y CONFIG_USB_GSPCA_PAC7302=y CONFIG_USB_GSPCA_PAC7311=y CONFIG_USB_GSPCA_SE401=y CONFIG_USB_GSPCA_SN9C2028=y CONFIG_USB_GSPCA_SN9C20X=y CONFIG_USB_GSPCA_SONIXB=y CONFIG_USB_GSPCA_SONIXJ=y CONFIG_USB_GSPCA_SPCA500=y CONFIG_USB_GSPCA_SPCA501=y CONFIG_USB_GSPCA_SPCA505=y CONFIG_USB_GSPCA_SPCA506=y CONFIG_USB_GSPCA_SPCA508=y CONFIG_USB_GSPCA_SPCA561=y CONFIG_USB_GSPCA_SPCA1528=y CONFIG_USB_GSPCA_SQ905=y CONFIG_USB_GSPCA_SQ905C=y CONFIG_USB_GSPCA_SQ930X=y CONFIG_USB_GSPCA_STK014=y CONFIG_USB_GSPCA_STK1135=y CONFIG_USB_GSPCA_STV0680=y CONFIG_USB_GSPCA_SUNPLUS=y CONFIG_USB_GSPCA_T613=y CONFIG_USB_GSPCA_TOPRO=y CONFIG_USB_GSPCA_TV8532=y CONFIG_USB_GSPCA_VC032X=y CONFIG_USB_GSPCA_VICAM=y CONFIG_USB_GSPCA_XIRLINK_CIT=y CONFIG_USB_GSPCA_ZC3XX=y CONFIG_USB_PWC=y CONFIG_USB_PWC_DEBUG=y CONFIG_USB_PWC_INPUT_EVDEV=y CONFIG_VIDEO_CPIA2=y CONFIG_USB_ZR364XX=y CONFIG_USB_STKWEBCAM=y CONFIG_USB_S2255=y CONFIG_VIDEO_USBTV=y # # Analog TV USB devices # CONFIG_VIDEO_PVRUSB2=y CONFIG_VIDEO_PVRUSB2_SYSFS=y CONFIG_VIDEO_PVRUSB2_DVB=y CONFIG_VIDEO_PVRUSB2_DEBUGIFC=y CONFIG_VIDEO_HDPVR=y CONFIG_VIDEO_USBVISION=y CONFIG_VIDEO_STK1160_COMMON=y CONFIG_VIDEO_STK1160=y # # Analog/digital TV USB devices # CONFIG_VIDEO_AU0828=y CONFIG_VIDEO_AU0828_V4L2=y CONFIG_VIDEO_AU0828_RC=y CONFIG_VIDEO_CX231XX=y CONFIG_VIDEO_CX231XX_RC=y CONFIG_VIDEO_CX231XX_DVB=y CONFIG_VIDEO_TM6000=y CONFIG_VIDEO_TM6000_DVB=y # # Digital TV USB devices # CONFIG_DVB_USB=y CONFIG_DVB_USB_DEBUG=y CONFIG_DVB_USB_A800=y CONFIG_DVB_USB_DIBUSB_MB=y CONFIG_DVB_USB_DIBUSB_MB_FAULTY=y CONFIG_DVB_USB_DIBUSB_MC=y CONFIG_DVB_USB_DIB0700=y CONFIG_DVB_USB_UMT_010=y CONFIG_DVB_USB_CXUSB=y CONFIG_DVB_USB_M920X=y CONFIG_DVB_USB_DIGITV=y CONFIG_DVB_USB_VP7045=y CONFIG_DVB_USB_VP702X=y CONFIG_DVB_USB_GP8PSK=y CONFIG_DVB_USB_NOVA_T_USB2=y CONFIG_DVB_USB_TTUSB2=y CONFIG_DVB_USB_DTT200U=y CONFIG_DVB_USB_OPERA1=y CONFIG_DVB_USB_AF9005=y CONFIG_DVB_USB_AF9005_REMOTE=y CONFIG_DVB_USB_PCTV452E=y CONFIG_DVB_USB_DW2102=y CONFIG_DVB_USB_CINERGY_T2=y CONFIG_DVB_USB_DTV5100=y CONFIG_DVB_USB_FRIIO=y CONFIG_DVB_USB_AZ6027=y CONFIG_DVB_USB_TECHNISAT_USB2=y CONFIG_DVB_USB_V2=y CONFIG_DVB_USB_AF9015=y CONFIG_DVB_USB_AF9035=y CONFIG_DVB_USB_ANYSEE=y CONFIG_DVB_USB_AU6610=y CONFIG_DVB_USB_AZ6007=y CONFIG_DVB_USB_CE6230=y CONFIG_DVB_USB_EC168=y CONFIG_DVB_USB_GL861=y CONFIG_DVB_USB_LME2510=y CONFIG_DVB_USB_MXL111SF=y CONFIG_DVB_USB_RTL28XXU=y CONFIG_DVB_TTUSB_BUDGET=y CONFIG_DVB_TTUSB_DEC=y CONFIG_SMS_USB_DRV=y CONFIG_DVB_B2C2_FLEXCOP_USB=y CONFIG_DVB_B2C2_FLEXCOP_USB_DEBUG=y # # Webcam, TV (analog/digital) USB devices # CONFIG_VIDEO_EM28XX=y CONFIG_VIDEO_EM28XX_V4L2=y CONFIG_VIDEO_EM28XX_DVB=y CONFIG_VIDEO_EM28XX_RC=y # # Software defined radio USB devices # CONFIG_USB_MSI2500=y CONFIG_USB_AIRSPY=y CONFIG_MEDIA_PCI_SUPPORT=y # # Media capture support # CONFIG_VIDEO_MEYE=y # # Media capture/analog TV support # CONFIG_VIDEO_IVTV=y CONFIG_VIDEO_FB_IVTV=y CONFIG_VIDEO_ZORAN=y CONFIG_VIDEO_ZORAN_DC30=y CONFIG_VIDEO_ZORAN_ZR36060=y CONFIG_VIDEO_ZORAN_BUZ=y CONFIG_VIDEO_ZORAN_DC10=y CONFIG_VIDEO_ZORAN_LML33=y CONFIG_VIDEO_ZORAN_LML33R10=y CONFIG_VIDEO_ZORAN_AVS6EYES=y CONFIG_VIDEO_HEXIUM_GEMINI=y CONFIG_VIDEO_HEXIUM_ORION=y CONFIG_VIDEO_MXB=y # # Media capture/analog/hybrid TV support # CONFIG_VIDEO_CX18=y CONFIG_VIDEO_CX25821=y CONFIG_VIDEO_CX88=y CONFIG_VIDEO_CX88_BLACKBIRD=y CONFIG_VIDEO_CX88_DVB=y CONFIG_VIDEO_CX88_ENABLE_VP3054=y CONFIG_VIDEO_CX88_VP3054=y CONFIG_VIDEO_CX88_MPEG=y CONFIG_VIDEO_BT848=y CONFIG_DVB_BT8XX=y CONFIG_VIDEO_SAA7134=y CONFIG_VIDEO_SAA7134_RC=y CONFIG_VIDEO_SAA7134_DVB=y CONFIG_VIDEO_SAA7164=y # # Media digital TV PCI Adapters # CONFIG_DVB_AV7110=y CONFIG_DVB_AV7110_OSD=y CONFIG_DVB_BUDGET_CORE=y CONFIG_DVB_BUDGET=y CONFIG_DVB_BUDGET_CI=y CONFIG_DVB_BUDGET_AV=y CONFIG_DVB_BUDGET_PATCH=y # CONFIG_DVB_B2C2_FLEXCOP_PCI is not set CONFIG_DVB_PLUTO2=y CONFIG_DVB_DM1105=y CONFIG_DVB_PT1=y CONFIG_MANTIS_CORE=y CONFIG_DVB_MANTIS=y CONFIG_DVB_HOPPER=y CONFIG_DVB_NGENE=y CONFIG_DVB_DDBRIDGE=y CONFIG_V4L_PLATFORM_DRIVERS=y CONFIG_VIDEO_CAFE_CCIC=y CONFIG_VIDEO_VIA_CAMERA=y CONFIG_SOC_CAMERA=y CONFIG_SOC_CAMERA_PLATFORM=y CONFIG_V4L_MEM2MEM_DRIVERS=y CONFIG_VIDEO_MEM2MEM_DEINTERLACE=y CONFIG_VIDEO_SH_VEU=y CONFIG_VIDEO_RENESAS_VSP1=y CONFIG_V4L_TEST_DRIVERS=y CONFIG_VIDEO_VIVI=y CONFIG_VIDEO_MEM2MEM_TESTDEV=y # # Supported MMC/SDIO adapters # CONFIG_SMS_SDIO_DRV=y CONFIG_RADIO_ADAPTERS=y CONFIG_RADIO_TEA575X=y CONFIG_RADIO_SI470X=y CONFIG_USB_SI470X=y CONFIG_RADIO_SI4713=y CONFIG_USB_SI4713=y CONFIG_PLATFORM_SI4713=y CONFIG_I2C_SI4713=y CONFIG_USB_MR800=y CONFIG_USB_DSBR=y CONFIG_RADIO_MAXIRADIO=y CONFIG_RADIO_SHARK=y CONFIG_RADIO_SHARK2=y CONFIG_USB_KEENE=y CONFIG_USB_RAREMONO=y CONFIG_USB_MA901=y CONFIG_RADIO_TEA5764=y CONFIG_RADIO_TEA5764_XTAL=y CONFIG_RADIO_SAA7706H=y CONFIG_RADIO_TEF6862=y CONFIG_RADIO_WL1273=y # # Texas Instruments WL128x FM driver (ST based) # CONFIG_RADIO_WL128X=y # # Supported FireWire (IEEE 1394) Adapters # CONFIG_DVB_FIREDTV=y CONFIG_DVB_FIREDTV_INPUT=y CONFIG_MEDIA_COMMON_OPTIONS=y # # common driver options # CONFIG_VIDEO_CX2341X=y CONFIG_VIDEO_BTCX=y CONFIG_VIDEO_TVEEPROM=y CONFIG_CYPRESS_FIRMWARE=y CONFIG_DVB_B2C2_FLEXCOP=y CONFIG_DVB_B2C2_FLEXCOP_DEBUG=y CONFIG_VIDEO_SAA7146=y CONFIG_VIDEO_SAA7146_VV=y CONFIG_SMS_SIANO_MDTV=y CONFIG_SMS_SIANO_RC=y CONFIG_SMS_SIANO_DEBUGFS=y # # Media ancillary drivers (tuners, sensors, i2c, frontends) # CONFIG_MEDIA_SUBDRV_AUTOSELECT=y CONFIG_MEDIA_ATTACH=y CONFIG_VIDEO_IR_I2C=y # # Audio decoders, processors and mixers # CONFIG_VIDEO_TVAUDIO=y CONFIG_VIDEO_TDA7432=y CONFIG_VIDEO_TDA9840=y CONFIG_VIDEO_TEA6415C=y CONFIG_VIDEO_TEA6420=y CONFIG_VIDEO_MSP3400=y CONFIG_VIDEO_CS5345=y CONFIG_VIDEO_CS53L32A=y CONFIG_VIDEO_WM8775=y CONFIG_VIDEO_WM8739=y CONFIG_VIDEO_VP27SMPX=y # # RDS decoders # CONFIG_VIDEO_SAA6588=y # # Video decoders # CONFIG_VIDEO_BT819=y CONFIG_VIDEO_BT856=y CONFIG_VIDEO_BT866=y CONFIG_VIDEO_KS0127=y CONFIG_VIDEO_SAA7110=y CONFIG_VIDEO_SAA711X=y CONFIG_VIDEO_TVP5150=y CONFIG_VIDEO_VPX3220=y # # Video and audio decoders # CONFIG_VIDEO_SAA717X=y CONFIG_VIDEO_CX25840=y # # Video encoders # CONFIG_VIDEO_SAA7127=y CONFIG_VIDEO_SAA7185=y CONFIG_VIDEO_ADV7170=y CONFIG_VIDEO_ADV7175=y # # Camera sensor devices # CONFIG_VIDEO_OV7670=y CONFIG_VIDEO_MT9V011=y # # Flash devices # # # Video improvement chips # CONFIG_VIDEO_UPD64031A=y CONFIG_VIDEO_UPD64083=y # # Audio/Video compression chips # CONFIG_VIDEO_SAA6752HS=y # # Miscellaneous helper chips # CONFIG_VIDEO_M52790=y # # Sensors used on soc_camera driver # # # soc_camera sensor drivers # CONFIG_SOC_CAMERA_IMX074=y CONFIG_SOC_CAMERA_MT9M001=y CONFIG_SOC_CAMERA_MT9M111=y CONFIG_SOC_CAMERA_MT9T031=y CONFIG_SOC_CAMERA_MT9T112=y CONFIG_SOC_CAMERA_MT9V022=y CONFIG_SOC_CAMERA_OV2640=y CONFIG_SOC_CAMERA_OV5642=y CONFIG_SOC_CAMERA_OV6650=y CONFIG_SOC_CAMERA_OV772X=y CONFIG_SOC_CAMERA_OV9640=y CONFIG_SOC_CAMERA_OV9740=y CONFIG_SOC_CAMERA_RJ54N1=y CONFIG_SOC_CAMERA_TW9910=y CONFIG_MEDIA_TUNER=y CONFIG_MEDIA_TUNER_SIMPLE=y CONFIG_MEDIA_TUNER_TDA8290=y CONFIG_MEDIA_TUNER_TDA827X=y CONFIG_MEDIA_TUNER_TDA18271=y CONFIG_MEDIA_TUNER_TDA9887=y CONFIG_MEDIA_TUNER_TEA5761=y CONFIG_MEDIA_TUNER_TEA5767=y CONFIG_MEDIA_TUNER_MSI001=y CONFIG_MEDIA_TUNER_MT20XX=y CONFIG_MEDIA_TUNER_MT2060=y CONFIG_MEDIA_TUNER_MT2063=y CONFIG_MEDIA_TUNER_MT2266=y CONFIG_MEDIA_TUNER_MT2131=y CONFIG_MEDIA_TUNER_QT1010=y CONFIG_MEDIA_TUNER_XC2028=y CONFIG_MEDIA_TUNER_XC5000=y CONFIG_MEDIA_TUNER_XC4000=y CONFIG_MEDIA_TUNER_MXL5005S=y CONFIG_MEDIA_TUNER_MXL5007T=y CONFIG_MEDIA_TUNER_MC44S803=y CONFIG_MEDIA_TUNER_MAX2165=y CONFIG_MEDIA_TUNER_TDA18218=y CONFIG_MEDIA_TUNER_FC0011=y CONFIG_MEDIA_TUNER_FC0012=y CONFIG_MEDIA_TUNER_FC0013=y CONFIG_MEDIA_TUNER_TDA18212=y CONFIG_MEDIA_TUNER_E4000=y CONFIG_MEDIA_TUNER_FC2580=y CONFIG_MEDIA_TUNER_M88TS2022=y CONFIG_MEDIA_TUNER_TUA9001=y CONFIG_MEDIA_TUNER_SI2157=y CONFIG_MEDIA_TUNER_IT913X=y CONFIG_MEDIA_TUNER_R820T=y # # Multistandard (satellite) frontends # CONFIG_DVB_STB0899=y CONFIG_DVB_STB6100=y CONFIG_DVB_STV090x=y CONFIG_DVB_STV6110x=y CONFIG_DVB_M88DS3103=y # # Multistandard (cable + terrestrial) frontends # CONFIG_DVB_DRXK=y CONFIG_DVB_TDA18271C2DD=y CONFIG_DVB_SI2165=y # # DVB-S (satellite) frontends # CONFIG_DVB_CX24110=y CONFIG_DVB_CX24123=y CONFIG_DVB_MT312=y CONFIG_DVB_ZL10036=y CONFIG_DVB_ZL10039=y CONFIG_DVB_S5H1420=y CONFIG_DVB_STV0288=y CONFIG_DVB_STB6000=y CONFIG_DVB_STV0299=y CONFIG_DVB_STV6110=y CONFIG_DVB_STV0900=y CONFIG_DVB_TDA8083=y CONFIG_DVB_TDA10086=y CONFIG_DVB_TDA8261=y CONFIG_DVB_VES1X93=y CONFIG_DVB_TUNER_ITD1000=y CONFIG_DVB_TUNER_CX24113=y CONFIG_DVB_TDA826X=y CONFIG_DVB_TUA6100=y CONFIG_DVB_CX24116=y CONFIG_DVB_SI21XX=y CONFIG_DVB_TS2020=y CONFIG_DVB_DS3000=y CONFIG_DVB_MB86A16=y CONFIG_DVB_TDA10071=y # # DVB-T (terrestrial) frontends # CONFIG_DVB_SP8870=y CONFIG_DVB_SP887X=y CONFIG_DVB_CX22700=y CONFIG_DVB_CX22702=y CONFIG_DVB_DRXD=y CONFIG_DVB_L64781=y CONFIG_DVB_TDA1004X=y CONFIG_DVB_NXT6000=y CONFIG_DVB_MT352=y CONFIG_DVB_ZL10353=y CONFIG_DVB_DIB3000MB=y CONFIG_DVB_DIB3000MC=y CONFIG_DVB_DIB7000M=y CONFIG_DVB_DIB7000P=y CONFIG_DVB_TDA10048=y CONFIG_DVB_AF9013=y CONFIG_DVB_EC100=y CONFIG_DVB_CXD2820R=y CONFIG_DVB_RTL2830=y CONFIG_DVB_RTL2832=y CONFIG_DVB_RTL2832_SDR=y CONFIG_DVB_SI2168=y # # DVB-C (cable) frontends # CONFIG_DVB_VES1820=y CONFIG_DVB_TDA10021=y CONFIG_DVB_TDA10023=y CONFIG_DVB_STV0297=y # # ATSC (North American/Korean Terrestrial/Cable DTV) frontends # CONFIG_DVB_NXT200X=y CONFIG_DVB_OR51211=y CONFIG_DVB_OR51132=y CONFIG_DVB_BCM3510=y CONFIG_DVB_LGDT330X=y CONFIG_DVB_LGDT3305=y CONFIG_DVB_LG2160=y CONFIG_DVB_S5H1409=y CONFIG_DVB_AU8522=y CONFIG_DVB_AU8522_DTV=y CONFIG_DVB_AU8522_V4L=y CONFIG_DVB_S5H1411=y # # ISDB-T (terrestrial) frontends # CONFIG_DVB_S921=y CONFIG_DVB_DIB8000=y CONFIG_DVB_MB86A20S=y # # Digital terrestrial only tuners/PLL # CONFIG_DVB_PLL=y CONFIG_DVB_TUNER_DIB0070=y CONFIG_DVB_TUNER_DIB0090=y # # SEC control devices for DVB-S # CONFIG_DVB_DRX39XYJ=y CONFIG_DVB_LNBP21=y CONFIG_DVB_LNBP22=y CONFIG_DVB_ISL6405=y CONFIG_DVB_ISL6421=y CONFIG_DVB_ISL6423=y CONFIG_DVB_A8293=y CONFIG_DVB_LGS8GXX=y CONFIG_DVB_ATBM8830=y CONFIG_DVB_TDA665x=y CONFIG_DVB_IX2505V=y CONFIG_DVB_M88RS2000=y CONFIG_DVB_AF9033=y # # Tools to develop new frontends # # CONFIG_DVB_DUMMY_FE is not set # # Graphics support # CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=y CONFIG_AGP_SIS=y CONFIG_AGP_VIA=y CONFIG_INTEL_GTT=y CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=16 CONFIG_VGA_SWITCHEROO=y # # Direct Rendering Manager # CONFIG_DRM=y CONFIG_DRM_USB=y CONFIG_DRM_KMS_HELPER=y CONFIG_DRM_KMS_FB_HELPER=y CONFIG_DRM_LOAD_EDID_FIRMWARE=y CONFIG_DRM_TTM=y # # I2C encoder or helper chips # CONFIG_DRM_I2C_CH7006=y CONFIG_DRM_I2C_SIL164=y CONFIG_DRM_I2C_NXP_TDA998X=y CONFIG_DRM_PTN3460=y CONFIG_DRM_TDFX=y CONFIG_DRM_R128=y CONFIG_DRM_RADEON=y CONFIG_DRM_RADEON_UMS=y CONFIG_DRM_NOUVEAU=y CONFIG_NOUVEAU_DEBUG=5 CONFIG_NOUVEAU_DEBUG_DEFAULT=3 CONFIG_DRM_NOUVEAU_BACKLIGHT=y CONFIG_DRM_I915=y CONFIG_DRM_I915_KMS=y CONFIG_DRM_I915_FBDEV=y CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=y CONFIG_DRM_MGA=y CONFIG_DRM_SIS=y CONFIG_DRM_VIA=y CONFIG_DRM_SAVAGE=y CONFIG_DRM_VMWGFX=y CONFIG_DRM_VMWGFX_FBCON=y CONFIG_DRM_GMA500=y CONFIG_DRM_GMA600=y CONFIG_DRM_GMA3600=y CONFIG_DRM_UDL=y CONFIG_DRM_AST=y CONFIG_DRM_MGAG200=y CONFIG_DRM_CIRRUS_QEMU=y CONFIG_DRM_QXL=y CONFIG_DRM_BOCHS=y # # Frame buffer Devices # CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_CMDLINE=y CONFIG_FB_DDC=y CONFIG_FB_BOOT_VESA_SUPPORT=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=y CONFIG_FB_SYS_COPYAREA=y CONFIG_FB_SYS_IMAGEBLIT=y CONFIG_FB_FOREIGN_ENDIAN=y CONFIG_FB_BOTH_ENDIAN=y # CONFIG_FB_BIG_ENDIAN is not set # CONFIG_FB_LITTLE_ENDIAN is not set CONFIG_FB_SYS_FOPS=y CONFIG_FB_DEFERRED_IO=y CONFIG_FB_HECUBA=y CONFIG_FB_SVGALIB=y # CONFIG_FB_MACMODES is not set CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # CONFIG_FB_CIRRUS=y CONFIG_FB_PM2=y CONFIG_FB_PM2_FIFO_DISCONNECT=y CONFIG_FB_CYBER2000=y CONFIG_FB_CYBER2000_DDC=y CONFIG_FB_ARC=y CONFIG_FB_ASILIANT=y CONFIG_FB_IMSTT=y # CONFIG_FB_VGA16 is not set CONFIG_FB_UVESA=y CONFIG_FB_VESA=y CONFIG_FB_EFI=y CONFIG_FB_N411=y CONFIG_FB_HGA=y CONFIG_FB_OPENCORES=y CONFIG_FB_S1D13XXX=y CONFIG_FB_NVIDIA=y CONFIG_FB_NVIDIA_I2C=y CONFIG_FB_NVIDIA_DEBUG=y CONFIG_FB_NVIDIA_BACKLIGHT=y CONFIG_FB_RIVA=y CONFIG_FB_RIVA_I2C=y CONFIG_FB_RIVA_DEBUG=y CONFIG_FB_RIVA_BACKLIGHT=y CONFIG_FB_I740=y CONFIG_FB_LE80578=y CONFIG_FB_CARILLO_RANCH=y CONFIG_FB_MATROX=y CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G=y CONFIG_FB_MATROX_I2C=y CONFIG_FB_MATROX_MAVEN=y CONFIG_FB_RADEON=y CONFIG_FB_RADEON_I2C=y CONFIG_FB_RADEON_BACKLIGHT=y CONFIG_FB_RADEON_DEBUG=y CONFIG_FB_ATY128=y CONFIG_FB_ATY128_BACKLIGHT=y CONFIG_FB_ATY=y CONFIG_FB_ATY_CT=y CONFIG_FB_ATY_GENERIC_LCD=y CONFIG_FB_ATY_GX=y CONFIG_FB_ATY_BACKLIGHT=y CONFIG_FB_S3=y CONFIG_FB_S3_DDC=y CONFIG_FB_SAVAGE=y CONFIG_FB_SAVAGE_I2C=y CONFIG_FB_SAVAGE_ACCEL=y CONFIG_FB_SIS=y CONFIG_FB_SIS_300=y CONFIG_FB_SIS_315=y CONFIG_FB_VIA=y CONFIG_FB_VIA_DIRECT_PROCFS=y CONFIG_FB_VIA_X_COMPATIBILITY=y CONFIG_FB_NEOMAGIC=y CONFIG_FB_KYRO=y CONFIG_FB_3DFX=y CONFIG_FB_3DFX_ACCEL=y CONFIG_FB_3DFX_I2C=y CONFIG_FB_VOODOO1=y CONFIG_FB_VT8623=y CONFIG_FB_TRIDENT=y CONFIG_FB_ARK=y CONFIG_FB_PM3=y CONFIG_FB_CARMINE=y CONFIG_FB_CARMINE_DRAM_EVAL=y # CONFIG_CARMINE_DRAM_CUSTOM is not set CONFIG_FB_SM501=y CONFIG_FB_SMSCUFX=y CONFIG_FB_UDL=y CONFIG_FB_VIRTUAL=y CONFIG_XEN_FBDEV_FRONTEND=y CONFIG_FB_METRONOME=y CONFIG_FB_MB862XX=y CONFIG_FB_MB862XX_PCI_GDC=y CONFIG_FB_MB862XX_I2C=y CONFIG_FB_BROADSHEET=y CONFIG_FB_AUO_K190X=y CONFIG_FB_AUO_K1900=y CONFIG_FB_AUO_K1901=y CONFIG_FB_HYPERV=y CONFIG_FB_SIMPLE=y CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_L4F00242T03=y CONFIG_LCD_LMS283GF05=y CONFIG_LCD_LTV350QV=y CONFIG_LCD_ILI922X=y CONFIG_LCD_ILI9320=y CONFIG_LCD_TDO24M=y CONFIG_LCD_VGG2432A4=y CONFIG_LCD_PLATFORM=y CONFIG_LCD_S6E63M0=y CONFIG_LCD_LD9040=y CONFIG_LCD_AMS369FG06=y CONFIG_LCD_LMS501KF03=y CONFIG_LCD_HX8357=y CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_BACKLIGHT_GENERIC=y CONFIG_BACKLIGHT_LM3533=y CONFIG_BACKLIGHT_CARILLO_RANCH=y CONFIG_BACKLIGHT_PWM=y CONFIG_BACKLIGHT_DA903X=y CONFIG_BACKLIGHT_DA9052=y CONFIG_BACKLIGHT_MAX8925=y CONFIG_BACKLIGHT_APPLE=y CONFIG_BACKLIGHT_SAHARA=y CONFIG_BACKLIGHT_WM831X=y CONFIG_BACKLIGHT_ADP5520=y CONFIG_BACKLIGHT_ADP8860=y CONFIG_BACKLIGHT_ADP8870=y CONFIG_BACKLIGHT_88PM860X=y CONFIG_BACKLIGHT_PCF50633=y CONFIG_BACKLIGHT_AAT2870=y CONFIG_BACKLIGHT_LM3630A=y CONFIG_BACKLIGHT_LM3639=y CONFIG_BACKLIGHT_LP855X=y CONFIG_BACKLIGHT_LP8788=y CONFIG_BACKLIGHT_PANDORA=y CONFIG_BACKLIGHT_TPS65217=y CONFIG_BACKLIGHT_AS3711=y CONFIG_BACKLIGHT_GPIO=y CONFIG_BACKLIGHT_LV5207LP=y CONFIG_BACKLIGHT_BD6107=y CONFIG_VGASTATE=y CONFIG_HDMI=y # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_LOGO=y CONFIG_LOGO_LINUX_MONO=y CONFIG_LOGO_LINUX_VGA16=y CONFIG_LOGO_LINUX_CLUT224=y # CONFIG_SOUND is not set # # HID support # CONFIG_HID=y CONFIG_HID_BATTERY_STRENGTH=y CONFIG_HIDRAW=y CONFIG_UHID=y CONFIG_HID_GENERIC=y # # Special HID drivers # CONFIG_HID_A4TECH=y CONFIG_HID_ACRUX=y CONFIG_HID_ACRUX_FF=y CONFIG_HID_APPLE=y CONFIG_HID_APPLEIR=y CONFIG_HID_AUREAL=y CONFIG_HID_BELKIN=y CONFIG_HID_CHERRY=y CONFIG_HID_CHICONY=y CONFIG_HID_CP2112=y CONFIG_HID_CYPRESS=y CONFIG_HID_DRAGONRISE=y CONFIG_DRAGONRISE_FF=y CONFIG_HID_EMS_FF=y CONFIG_HID_ELECOM=y CONFIG_HID_ELO=y CONFIG_HID_EZKEY=y CONFIG_HID_HOLTEK=y CONFIG_HOLTEK_FF=y CONFIG_HID_GT683R=y CONFIG_HID_HUION=y CONFIG_HID_KEYTOUCH=y CONFIG_HID_KYE=y CONFIG_HID_UCLOGIC=y CONFIG_HID_WALTOP=y CONFIG_HID_GYRATION=y CONFIG_HID_ICADE=y CONFIG_HID_TWINHAN=y CONFIG_HID_KENSINGTON=y CONFIG_HID_LCPOWER=y CONFIG_HID_LENOVO=y CONFIG_HID_LOGITECH=y CONFIG_HID_LOGITECH_DJ=y CONFIG_LOGITECH_FF=y CONFIG_LOGIRUMBLEPAD2_FF=y CONFIG_LOGIG940_FF=y CONFIG_LOGIWHEELS_FF=y CONFIG_HID_MAGICMOUSE=y CONFIG_HID_MICROSOFT=y CONFIG_HID_MONTEREY=y CONFIG_HID_MULTITOUCH=y CONFIG_HID_NTRIG=y CONFIG_HID_ORTEK=y CONFIG_HID_PANTHERLORD=y CONFIG_PANTHERLORD_FF=y CONFIG_HID_PENMOUNT=y CONFIG_HID_PETALYNX=y CONFIG_HID_PICOLCD=y CONFIG_HID_PICOLCD_FB=y CONFIG_HID_PICOLCD_BACKLIGHT=y CONFIG_HID_PICOLCD_LCD=y CONFIG_HID_PICOLCD_LEDS=y CONFIG_HID_PICOLCD_CIR=y CONFIG_HID_PRIMAX=y CONFIG_HID_ROCCAT=y CONFIG_HID_SAITEK=y CONFIG_HID_SAMSUNG=y CONFIG_HID_SONY=y CONFIG_SONY_FF=y CONFIG_HID_SPEEDLINK=y CONFIG_HID_STEELSERIES=y CONFIG_HID_SUNPLUS=y CONFIG_HID_RMI=y CONFIG_HID_GREENASIA=y CONFIG_GREENASIA_FF=y CONFIG_HID_HYPERV_MOUSE=y CONFIG_HID_SMARTJOYPLUS=y CONFIG_SMARTJOYPLUS_FF=y CONFIG_HID_TIVO=y CONFIG_HID_TOPSEED=y CONFIG_HID_THINGM=y CONFIG_HID_THRUSTMASTER=y CONFIG_THRUSTMASTER_FF=y CONFIG_HID_WACOM=y CONFIG_HID_WIIMOTE=y CONFIG_HID_XINMO=y CONFIG_HID_ZEROPLUS=y CONFIG_ZEROPLUS_FF=y CONFIG_HID_ZYDACRON=y CONFIG_HID_SENSOR_HUB=y # # USB HID support # CONFIG_USB_HID=y CONFIG_HID_PID=y CONFIG_USB_HIDDEV=y # # I2C HID support # CONFIG_I2C_HID=y CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_SUPPORT=y CONFIG_USB_COMMON=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y # # Miscellaneous USB options # CONFIG_USB_DEFAULT_PERSIST=y CONFIG_USB_DYNAMIC_MINORS=y CONFIG_USB_OTG=y CONFIG_USB_OTG_WHITELIST=y CONFIG_USB_OTG_BLACKLIST_HUB=y CONFIG_USB_OTG_FSM=y CONFIG_USB_MON=y CONFIG_USB_WUSB=y CONFIG_USB_WUSB_CBAF=y CONFIG_USB_WUSB_CBAF_DEBUG=y # # USB Host Controller Drivers # CONFIG_USB_C67X00_HCD=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PLATFORM=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y CONFIG_USB_EHCI_PCI=y CONFIG_USB_EHCI_HCD_PLATFORM=y CONFIG_USB_OXU210HP_HCD=y CONFIG_USB_ISP116X_HCD=y CONFIG_USB_ISP1760_HCD=y CONFIG_USB_ISP1362_HCD=y CONFIG_USB_FUSBH200_HCD=y CONFIG_USB_FOTG210_HCD=y CONFIG_USB_MAX3421_HCD=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_HCD_PCI=y CONFIG_USB_OHCI_HCD_SSB=y CONFIG_USB_OHCI_HCD_PLATFORM=y CONFIG_USB_UHCI_HCD=y CONFIG_USB_U132_HCD=y CONFIG_USB_SL811_HCD=y CONFIG_USB_SL811_HCD_ISO=y CONFIG_USB_SL811_CS=y CONFIG_USB_R8A66597_HCD=y CONFIG_USB_RENESAS_USBHS_HCD=y CONFIG_USB_WHCI_HCD=y CONFIG_USB_HWA_HCD=y CONFIG_USB_HCD_BCMA=y CONFIG_USB_HCD_SSB=y CONFIG_USB_HCD_TEST_MODE=y CONFIG_USB_RENESAS_USBHS=y # # USB Device Class drivers # CONFIG_USB_ACM=y CONFIG_USB_PRINTER=y CONFIG_USB_WDM=y CONFIG_USB_TMC=y # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may # # # also be needed; see USB_STORAGE Help for more info # CONFIG_USB_STORAGE=y CONFIG_USB_STORAGE_DEBUG=y CONFIG_USB_STORAGE_REALTEK=y CONFIG_REALTEK_AUTOPM=y CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_USBAT=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y CONFIG_USB_STORAGE_ALAUDA=y CONFIG_USB_STORAGE_ONETOUCH=y CONFIG_USB_STORAGE_KARMA=y CONFIG_USB_STORAGE_CYPRESS_ATACB=y CONFIG_USB_STORAGE_ENE_UB6250=y CONFIG_USB_UAS=y # # USB Imaging devices # CONFIG_USB_MDC800=y CONFIG_USB_MICROTEK=y CONFIG_USBIP_CORE=y # CONFIG_USBIP_VHCI_HCD is not set CONFIG_USBIP_HOST=y CONFIG_USBIP_DEBUG=y CONFIG_USB_MUSB_HDRC=y # CONFIG_USB_MUSB_HOST is not set # CONFIG_USB_MUSB_GADGET is not set CONFIG_USB_MUSB_DUAL_ROLE=y CONFIG_USB_MUSB_TUSB6010=y # CONFIG_USB_MUSB_UX500 is not set CONFIG_MUSB_PIO_ONLY=y CONFIG_USB_DWC3=y # CONFIG_USB_DWC3_HOST is not set # CONFIG_USB_DWC3_GADGET is not set CONFIG_USB_DWC3_DUAL_ROLE=y # # Platform Glue Driver Support # CONFIG_USB_DWC3_PCI=y # # Debugging features # CONFIG_USB_DWC3_DEBUG=y CONFIG_USB_DWC3_VERBOSE=y CONFIG_DWC3_HOST_USB3_LPM_ENABLE=y CONFIG_USB_DWC2=y CONFIG_USB_DWC2_HOST=y CONFIG_USB_DWC2_PLATFORM=y CONFIG_USB_DWC2_PCI=y # # Gadget mode requires USB Gadget support to be enabled # CONFIG_USB_DWC2_PERIPHERAL=y CONFIG_USB_DWC2_DEBUG=y CONFIG_USB_DWC2_VERBOSE=y CONFIG_USB_DWC2_TRACK_MISSED_SOFS=y CONFIG_USB_DWC2_DEBUG_PERIODIC=y CONFIG_USB_CHIPIDEA=y CONFIG_USB_CHIPIDEA_UDC=y CONFIG_USB_CHIPIDEA_HOST=y CONFIG_USB_CHIPIDEA_DEBUG=y # # USB port drivers # CONFIG_USB_SERIAL=y CONFIG_USB_SERIAL_CONSOLE=y CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_SIMPLE=y CONFIG_USB_SERIAL_AIRCABLE=y CONFIG_USB_SERIAL_ARK3116=y CONFIG_USB_SERIAL_BELKIN=y CONFIG_USB_SERIAL_CH341=y CONFIG_USB_SERIAL_WHITEHEAT=y CONFIG_USB_SERIAL_DIGI_ACCELEPORT=y CONFIG_USB_SERIAL_CP210X=y CONFIG_USB_SERIAL_CYPRESS_M8=y CONFIG_USB_SERIAL_EMPEG=y CONFIG_USB_SERIAL_FTDI_SIO=y CONFIG_USB_SERIAL_VISOR=y CONFIG_USB_SERIAL_IPAQ=y CONFIG_USB_SERIAL_IR=y CONFIG_USB_SERIAL_EDGEPORT=y CONFIG_USB_SERIAL_EDGEPORT_TI=y CONFIG_USB_SERIAL_F81232=y CONFIG_USB_SERIAL_GARMIN=y CONFIG_USB_SERIAL_IPW=y CONFIG_USB_SERIAL_IUU=y CONFIG_USB_SERIAL_KEYSPAN_PDA=y CONFIG_USB_SERIAL_KEYSPAN=y CONFIG_USB_SERIAL_KEYSPAN_MPR=y CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y CONFIG_USB_SERIAL_KLSI=y CONFIG_USB_SERIAL_KOBIL_SCT=y CONFIG_USB_SERIAL_MCT_U232=y CONFIG_USB_SERIAL_METRO=y CONFIG_USB_SERIAL_MOS7720=y CONFIG_USB_SERIAL_MOS7840=y CONFIG_USB_SERIAL_MXUPORT=y CONFIG_USB_SERIAL_NAVMAN=y CONFIG_USB_SERIAL_PL2303=y CONFIG_USB_SERIAL_OTI6858=y CONFIG_USB_SERIAL_QCAUX=y CONFIG_USB_SERIAL_QUALCOMM=y CONFIG_USB_SERIAL_SPCP8X5=y CONFIG_USB_SERIAL_SAFE=y CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_SIERRAWIRELESS=y CONFIG_USB_SERIAL_SYMBOL=y CONFIG_USB_SERIAL_TI=y CONFIG_USB_SERIAL_CYBERJACK=y CONFIG_USB_SERIAL_XIRCOM=y CONFIG_USB_SERIAL_WWAN=y CONFIG_USB_SERIAL_OPTION=y CONFIG_USB_SERIAL_OMNINET=y CONFIG_USB_SERIAL_OPTICON=y CONFIG_USB_SERIAL_XSENS_MT=y CONFIG_USB_SERIAL_WISHBONE=y CONFIG_USB_SERIAL_ZTE=y CONFIG_USB_SERIAL_SSU100=y CONFIG_USB_SERIAL_QT2=y CONFIG_USB_SERIAL_DEBUG=y # # USB Miscellaneous drivers # CONFIG_USB_EMI62=y CONFIG_USB_EMI26=y CONFIG_USB_ADUTUX=y CONFIG_USB_SEVSEG=y CONFIG_USB_RIO500=y CONFIG_USB_LEGOTOWER=y CONFIG_USB_LCD=y CONFIG_USB_LED=y CONFIG_USB_CYPRESS_CY7C63=y CONFIG_USB_CYTHERM=y CONFIG_USB_IDMOUSE=y CONFIG_USB_FTDI_ELAN=y CONFIG_USB_APPLEDISPLAY=y CONFIG_USB_SISUSBVGA=y CONFIG_USB_SISUSBVGA_CON=y CONFIG_USB_LD=y CONFIG_USB_TRANCEVIBRATOR=y CONFIG_USB_IOWARRIOR=y CONFIG_USB_TEST=y CONFIG_USB_EHSET_TEST_FIXTURE=y CONFIG_USB_ISIGHTFW=y CONFIG_USB_YUREX=y CONFIG_USB_EZUSB_FX2=y CONFIG_USB_HSIC_USB3503=y CONFIG_USB_LINK_LAYER_TEST=y CONFIG_USB_ATM=y CONFIG_USB_SPEEDTOUCH=y CONFIG_USB_CXACRU=y CONFIG_USB_UEAGLEATM=y CONFIG_USB_XUSBATM=y # # USB Physical Layer drivers # CONFIG_USB_PHY=y CONFIG_NOP_USB_XCEIV=y CONFIG_USB_GPIO_VBUS=y CONFIG_TAHVO_USB=y CONFIG_TAHVO_USB_HOST_BY_DEFAULT=y CONFIG_USB_ISP1301=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_DEBUG=y CONFIG_USB_GADGET_VERBOSE=y CONFIG_USB_GADGET_DEBUG_FILES=y CONFIG_USB_GADGET_DEBUG_FS=y CONFIG_USB_GADGET_VBUS_DRAW=2 CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2 # # USB Peripheral Controller # CONFIG_USB_FOTG210_UDC=y CONFIG_USB_GR_UDC=y CONFIG_USB_R8A66597=y CONFIG_USB_RENESAS_USBHS_UDC=y CONFIG_USB_PXA27X=y CONFIG_USB_MV_UDC=y CONFIG_USB_MV_U3D=y CONFIG_USB_M66592=y CONFIG_USB_AMD5536UDC=y CONFIG_USB_NET2272=y CONFIG_USB_NET2272_DMA=y CONFIG_USB_NET2280=y CONFIG_USB_GOKU=y CONFIG_USB_EG20T=y CONFIG_USB_DUMMY_HCD=y CONFIG_USB_LIBCOMPOSITE=m CONFIG_USB_U_ETHER=m CONFIG_USB_F_ECM=m CONFIG_USB_F_EEM=m CONFIG_USB_F_SUBSET=m CONFIG_USB_F_RNDIS=m # CONFIG_USB_CONFIGFS is not set # CONFIG_USB_ZERO is not set CONFIG_USB_ETH=m CONFIG_USB_ETH_RNDIS=y CONFIG_USB_ETH_EEM=y # CONFIG_USB_G_NCM is not set # CONFIG_USB_GADGETFS is not set # CONFIG_USB_FUNCTIONFS is not set # CONFIG_USB_MASS_STORAGE is not set # CONFIG_USB_GADGET_TARGET is not set # CONFIG_USB_G_SERIAL is not set # CONFIG_USB_G_PRINTER is not set # CONFIG_USB_CDC_COMPOSITE is not set # CONFIG_USB_G_ACM_MS is not set # CONFIG_USB_G_MULTI is not set # CONFIG_USB_G_HID is not set # CONFIG_USB_G_DBGP is not set # CONFIG_USB_G_WEBCAM is not set CONFIG_UWB=y CONFIG_UWB_HWA=y CONFIG_UWB_WHCI=y CONFIG_UWB_I1480U=y CONFIG_MMC=y CONFIG_MMC_DEBUG=y CONFIG_MMC_CLKGATE=y # # MMC/SD/SDIO Card Drivers # CONFIG_MMC_BLOCK=y CONFIG_MMC_BLOCK_MINORS=8 CONFIG_MMC_BLOCK_BOUNCE=y CONFIG_SDIO_UART=y CONFIG_MMC_TEST=y # # MMC/SD/SDIO Host Controller Drivers # CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_PCI=y CONFIG_MMC_RICOH_MMC=y CONFIG_MMC_SDHCI_ACPI=y CONFIG_MMC_SDHCI_PLTFM=y CONFIG_MMC_SDHCI_PXAV3=y CONFIG_MMC_SDHCI_PXAV2=y CONFIG_MMC_WBSD=y CONFIG_MMC_TIFM_SD=y CONFIG_MMC_SPI=y CONFIG_MMC_SDRICOH_CS=y CONFIG_MMC_CB710=y CONFIG_MMC_VIA_SDMMC=y CONFIG_MMC_VUB300=y CONFIG_MMC_USHC=y CONFIG_MMC_USDHI6ROL0=y CONFIG_MMC_REALTEK_PCI=y CONFIG_MMC_REALTEK_USB=y CONFIG_MEMSTICK=y CONFIG_MEMSTICK_DEBUG=y # # MemoryStick drivers # CONFIG_MEMSTICK_UNSAFE_RESUME=y CONFIG_MSPRO_BLOCK=y CONFIG_MS_BLOCK=y # # MemoryStick Host Controller Drivers # CONFIG_MEMSTICK_TIFM_MS=y CONFIG_MEMSTICK_JMICRON_38X=y CONFIG_MEMSTICK_R592=y CONFIG_MEMSTICK_REALTEK_PCI=y CONFIG_MEMSTICK_REALTEK_USB=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # # LED drivers # CONFIG_LEDS_88PM860X=y CONFIG_LEDS_LM3530=y CONFIG_LEDS_LM3533=y CONFIG_LEDS_LM3642=y CONFIG_LEDS_PCA9532=y CONFIG_LEDS_PCA9532_GPIO=y CONFIG_LEDS_GPIO=y CONFIG_LEDS_LP3944=y CONFIG_LEDS_LP55XX_COMMON=y CONFIG_LEDS_LP5521=y CONFIG_LEDS_LP5523=y CONFIG_LEDS_LP5562=y CONFIG_LEDS_LP8501=y CONFIG_LEDS_LP8788=y CONFIG_LEDS_CLEVO_MAIL=y CONFIG_LEDS_PCA955X=y CONFIG_LEDS_PCA963X=y # CONFIG_LEDS_WM831X_STATUS is not set # CONFIG_LEDS_WM8350 is not set # CONFIG_LEDS_DA903X is not set # CONFIG_LEDS_DA9052 is not set CONFIG_LEDS_DAC124S085=y CONFIG_LEDS_PWM=y CONFIG_LEDS_REGULATOR=y CONFIG_LEDS_BD2802=y CONFIG_LEDS_INTEL_SS4200=y CONFIG_LEDS_LT3593=y # CONFIG_LEDS_ADP5520 is not set CONFIG_LEDS_DELL_NETBOOKS=y CONFIG_LEDS_MC13783=y CONFIG_LEDS_TCA6507=y # CONFIG_LEDS_MAX8997 is not set # CONFIG_LEDS_LM355x is not set # # LED driver for blink(1) USB RGB LED is under Special HID drivers (HID_THINGM) # CONFIG_LEDS_BLINKM=y # # LED Triggers # CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=y CONFIG_LEDS_TRIGGER_ONESHOT=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_LEDS_TRIGGER_BACKLIGHT=y CONFIG_LEDS_TRIGGER_CPU=y CONFIG_LEDS_TRIGGER_GPIO=y CONFIG_LEDS_TRIGGER_DEFAULT_ON=y # # iptables trigger is under Netfilter config (LED target) # CONFIG_LEDS_TRIGGER_TRANSIENT=y CONFIG_LEDS_TRIGGER_CAMERA=y CONFIG_ACCESSIBILITY=y # CONFIG_A11Y_BRAILLE_CONSOLE is not set CONFIG_INFINIBAND=y CONFIG_INFINIBAND_USER_MAD=y CONFIG_INFINIBAND_USER_ACCESS=y CONFIG_INFINIBAND_USER_MEM=y CONFIG_INFINIBAND_ADDR_TRANS=y CONFIG_INFINIBAND_MTHCA=y CONFIG_INFINIBAND_MTHCA_DEBUG=y CONFIG_INFINIBAND_IPATH=y CONFIG_INFINIBAND_QIB=y CONFIG_INFINIBAND_QIB_DCA=y CONFIG_INFINIBAND_AMSO1100=y CONFIG_INFINIBAND_AMSO1100_DEBUG=y CONFIG_INFINIBAND_CXGB3=y CONFIG_INFINIBAND_CXGB3_DEBUG=y CONFIG_INFINIBAND_CXGB4=y CONFIG_MLX4_INFINIBAND=y CONFIG_MLX5_INFINIBAND=y CONFIG_INFINIBAND_NES=y CONFIG_INFINIBAND_NES_DEBUG=y CONFIG_INFINIBAND_OCRDMA=y CONFIG_INFINIBAND_USNIC=y CONFIG_INFINIBAND_IPOIB=y CONFIG_INFINIBAND_IPOIB_CM=y CONFIG_INFINIBAND_IPOIB_DEBUG=y CONFIG_INFINIBAND_IPOIB_DEBUG_DATA=y CONFIG_INFINIBAND_SRP=y CONFIG_INFINIBAND_SRPT=y CONFIG_INFINIBAND_ISER=y CONFIG_INFINIBAND_ISERT=y # CONFIG_EDAC is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_SYSTOHC=y CONFIG_RTC_HCTOSYS_DEVICE="y" CONFIG_RTC_DEBUG=y # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y CONFIG_RTC_INTF_DEV_UIE_EMUL=y CONFIG_RTC_DRV_TEST=y # # I2C RTC drivers # CONFIG_RTC_DRV_88PM860X=y CONFIG_RTC_DRV_88PM80X=y CONFIG_RTC_DRV_DS1307=y CONFIG_RTC_DRV_DS1374=y CONFIG_RTC_DRV_DS1672=y CONFIG_RTC_DRV_DS3232=y CONFIG_RTC_DRV_LP8788=y CONFIG_RTC_DRV_MAX6900=y CONFIG_RTC_DRV_MAX8907=y # CONFIG_RTC_DRV_MAX8925 is not set # CONFIG_RTC_DRV_MAX8998 is not set CONFIG_RTC_DRV_MAX8997=y CONFIG_RTC_DRV_MAX77686=y CONFIG_RTC_DRV_RS5C372=y CONFIG_RTC_DRV_ISL1208=y CONFIG_RTC_DRV_ISL12022=y CONFIG_RTC_DRV_ISL12057=y CONFIG_RTC_DRV_X1205=y CONFIG_RTC_DRV_PALMAS=y CONFIG_RTC_DRV_PCF2127=y CONFIG_RTC_DRV_PCF8523=y CONFIG_RTC_DRV_PCF8563=y CONFIG_RTC_DRV_PCF85063=y CONFIG_RTC_DRV_PCF8583=y CONFIG_RTC_DRV_M41T80=y CONFIG_RTC_DRV_M41T80_WDT=y CONFIG_RTC_DRV_BQ32K=y CONFIG_RTC_DRV_TWL4030=y CONFIG_RTC_DRV_TPS6586X=y # CONFIG_RTC_DRV_TPS65910 is not set CONFIG_RTC_DRV_TPS80031=y # CONFIG_RTC_DRV_RC5T583 is not set CONFIG_RTC_DRV_S35390A=y CONFIG_RTC_DRV_FM3130=y CONFIG_RTC_DRV_RX8581=y CONFIG_RTC_DRV_RX8025=y CONFIG_RTC_DRV_EM3027=y CONFIG_RTC_DRV_RV3029C2=y CONFIG_RTC_DRV_S5M=y # # SPI RTC drivers # CONFIG_RTC_DRV_M41T93=y CONFIG_RTC_DRV_M41T94=y CONFIG_RTC_DRV_DS1305=y CONFIG_RTC_DRV_DS1343=y CONFIG_RTC_DRV_DS1347=y CONFIG_RTC_DRV_DS1390=y CONFIG_RTC_DRV_MAX6902=y CONFIG_RTC_DRV_R9701=y CONFIG_RTC_DRV_RS5C348=y CONFIG_RTC_DRV_DS3234=y CONFIG_RTC_DRV_PCF2123=y CONFIG_RTC_DRV_RX4581=y CONFIG_RTC_DRV_MCP795=y # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=y CONFIG_RTC_DRV_DS1286=y CONFIG_RTC_DRV_DS1511=y CONFIG_RTC_DRV_DS1553=y CONFIG_RTC_DRV_DS1742=y # CONFIG_RTC_DRV_DS2404 is not set # CONFIG_RTC_DRV_DA9052 is not set CONFIG_RTC_DRV_DA9055=y CONFIG_RTC_DRV_DA9063=y CONFIG_RTC_DRV_EFI=y CONFIG_RTC_DRV_STK17TA8=y CONFIG_RTC_DRV_M48T86=y CONFIG_RTC_DRV_M48T35=y CONFIG_RTC_DRV_M48T59=y CONFIG_RTC_DRV_MSM6242=y CONFIG_RTC_DRV_BQ4802=y CONFIG_RTC_DRV_RP5C01=y CONFIG_RTC_DRV_V3020=y # CONFIG_RTC_DRV_WM831X is not set # CONFIG_RTC_DRV_WM8350 is not set # CONFIG_RTC_DRV_PCF50633 is not set CONFIG_RTC_DRV_AB3100=y # # on-CPU RTC drivers # # CONFIG_RTC_DRV_PCAP is not set CONFIG_RTC_DRV_MC13XXX=y CONFIG_RTC_DRV_XGENE=y # # HID Sensor RTC drivers # CONFIG_RTC_DRV_HID_SENSOR_TIME=y CONFIG_DMADEVICES=y CONFIG_DMADEVICES_DEBUG=y CONFIG_DMADEVICES_VDEBUG=y # # DMA Devices # CONFIG_INTEL_MIC_X100_DMA=y CONFIG_INTEL_MID_DMAC=y CONFIG_INTEL_IOATDMA=y CONFIG_DW_DMAC_CORE=y CONFIG_DW_DMAC=y CONFIG_DW_DMAC_PCI=y CONFIG_DMA_ENGINE=y CONFIG_DMA_ACPI=y # # DMA Clients # CONFIG_ASYNC_TX_DMA=y CONFIG_DMATEST=y CONFIG_DMA_ENGINE_RAID=y CONFIG_DCA=y CONFIG_AUXDISPLAY=y CONFIG_UIO=y CONFIG_UIO_CIF=y CONFIG_UIO_PDRV_GENIRQ=y CONFIG_UIO_DMEM_GENIRQ=y CONFIG_UIO_AEC=y CONFIG_UIO_SERCOS3=y CONFIG_UIO_PCI_GENERIC=y CONFIG_UIO_NETX=y CONFIG_UIO_MF624=y CONFIG_VFIO_IOMMU_TYPE1=y CONFIG_VFIO=y CONFIG_VFIO_PCI=y CONFIG_VFIO_PCI_VGA=y CONFIG_VIRT_DRIVERS=y CONFIG_VIRTIO=y # # Virtio drivers # CONFIG_VIRTIO_PCI=y CONFIG_VIRTIO_BALLOON=y CONFIG_VIRTIO_MMIO=y CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y # # Microsoft Hyper-V guest support # CONFIG_HYPERV=y CONFIG_HYPERV_UTILS=y CONFIG_HYPERV_BALLOON=y # # Xen driver support # CONFIG_XEN_BALLOON=y CONFIG_XEN_SELFBALLOONING=y CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y CONFIG_XEN_SCRUB_PAGES=y CONFIG_XEN_DEV_EVTCHN=y CONFIG_XEN_BACKEND=y CONFIG_XENFS=y CONFIG_XEN_COMPAT_XENFS=y CONFIG_XEN_SYS_HYPERVISOR=y CONFIG_XEN_XENBUS_FRONTEND=y CONFIG_XEN_GNTDEV=y CONFIG_XEN_GRANT_DEV_ALLOC=y CONFIG_SWIOTLB_XEN=y CONFIG_XEN_TMEM=m CONFIG_XEN_PCIDEV_BACKEND=y CONFIG_XEN_SCSI_BACKEND=y CONFIG_XEN_PRIVCMD=y CONFIG_XEN_ACPI_PROCESSOR=y CONFIG_XEN_MCE_LOG=y CONFIG_XEN_HAVE_PVMMU=y CONFIG_XEN_EFI=y CONFIG_STAGING=y CONFIG_ET131X=y CONFIG_SLICOSS=y CONFIG_PRISM2_USB=y CONFIG_COMEDI=m CONFIG_COMEDI_DEBUG=y CONFIG_COMEDI_DEFAULT_BUF_SIZE_KB=2048 CONFIG_COMEDI_DEFAULT_BUF_MAXSIZE_KB=20480 CONFIG_COMEDI_MISC_DRIVERS=y CONFIG_COMEDI_BOND=m CONFIG_COMEDI_TEST=m CONFIG_COMEDI_PARPORT=m CONFIG_COMEDI_SERIAL2002=m CONFIG_COMEDI_SKEL=m CONFIG_COMEDI_ISA_DRIVERS=y CONFIG_COMEDI_PCL711=m CONFIG_COMEDI_PCL724=m CONFIG_COMEDI_PCL726=m CONFIG_COMEDI_PCL730=m CONFIG_COMEDI_PCL812=m CONFIG_COMEDI_PCL816=m CONFIG_COMEDI_PCL818=m CONFIG_COMEDI_PCM3724=m CONFIG_COMEDI_AMPLC_DIO200_ISA=m CONFIG_COMEDI_AMPLC_PC236_ISA=m CONFIG_COMEDI_AMPLC_PC263_ISA=m CONFIG_COMEDI_RTI800=m CONFIG_COMEDI_RTI802=m # CONFIG_COMEDI_DAC02 is not set CONFIG_COMEDI_DAS16M1=m CONFIG_COMEDI_DAS08_ISA=m CONFIG_COMEDI_DAS16=m CONFIG_COMEDI_DAS800=m CONFIG_COMEDI_DAS1800=m CONFIG_COMEDI_DAS6402=m CONFIG_COMEDI_DT2801=m CONFIG_COMEDI_DT2811=m CONFIG_COMEDI_DT2814=m CONFIG_COMEDI_DT2815=m CONFIG_COMEDI_DT2817=m CONFIG_COMEDI_DT282X=m CONFIG_COMEDI_DMM32AT=m CONFIG_COMEDI_UNIOXX5=m CONFIG_COMEDI_FL512=m CONFIG_COMEDI_AIO_AIO12_8=m CONFIG_COMEDI_AIO_IIRO_16=m CONFIG_COMEDI_II_PCI20KC=m CONFIG_COMEDI_C6XDIGIO=m CONFIG_COMEDI_MPC624=m CONFIG_COMEDI_ADQ12B=m CONFIG_COMEDI_NI_AT_A2150=m CONFIG_COMEDI_NI_AT_AO=m CONFIG_COMEDI_NI_ATMIO=m CONFIG_COMEDI_NI_ATMIO16D=m CONFIG_COMEDI_NI_LABPC_ISA=m CONFIG_COMEDI_PCMAD=m CONFIG_COMEDI_PCMDA12=m CONFIG_COMEDI_PCMMIO=m CONFIG_COMEDI_PCMUIO=m CONFIG_COMEDI_MULTIQ3=m CONFIG_COMEDI_S526=m CONFIG_COMEDI_PCI_DRIVERS=y CONFIG_COMEDI_8255_PCI=m CONFIG_COMEDI_ADDI_WATCHDOG=m CONFIG_COMEDI_ADDI_APCI_035=m CONFIG_COMEDI_ADDI_APCI_1032=m CONFIG_COMEDI_ADDI_APCI_1500=m CONFIG_COMEDI_ADDI_APCI_1516=m CONFIG_COMEDI_ADDI_APCI_1564=m CONFIG_COMEDI_ADDI_APCI_16XX=m CONFIG_COMEDI_ADDI_APCI_2032=m CONFIG_COMEDI_ADDI_APCI_2200=m CONFIG_COMEDI_ADDI_APCI_3120=m CONFIG_COMEDI_ADDI_APCI_3501=m CONFIG_COMEDI_ADDI_APCI_3XXX=m CONFIG_COMEDI_ADL_PCI6208=m CONFIG_COMEDI_ADL_PCI7X3X=m CONFIG_COMEDI_ADL_PCI8164=m CONFIG_COMEDI_ADL_PCI9111=m CONFIG_COMEDI_ADL_PCI9118=m CONFIG_COMEDI_ADV_PCI1710=m CONFIG_COMEDI_ADV_PCI1723=m CONFIG_COMEDI_ADV_PCI1724=m CONFIG_COMEDI_ADV_PCI_DIO=m CONFIG_COMEDI_AMPLC_DIO200_PCI=m CONFIG_COMEDI_AMPLC_PC236_PCI=m CONFIG_COMEDI_AMPLC_PC263_PCI=m CONFIG_COMEDI_AMPLC_PCI224=m CONFIG_COMEDI_AMPLC_PCI230=m CONFIG_COMEDI_CONTEC_PCI_DIO=m CONFIG_COMEDI_DAS08_PCI=m CONFIG_COMEDI_DT3000=m CONFIG_COMEDI_DYNA_PCI10XX=m CONFIG_COMEDI_GSC_HPDI=m CONFIG_COMEDI_MF6X4=m CONFIG_COMEDI_ICP_MULTI=m CONFIG_COMEDI_DAQBOARD2000=m CONFIG_COMEDI_JR3_PCI=m CONFIG_COMEDI_KE_COUNTER=m CONFIG_COMEDI_CB_PCIDAS64=m CONFIG_COMEDI_CB_PCIDAS=m CONFIG_COMEDI_CB_PCIDDA=m CONFIG_COMEDI_CB_PCIMDAS=m CONFIG_COMEDI_CB_PCIMDDA=m CONFIG_COMEDI_ME4000=m CONFIG_COMEDI_ME_DAQ=m CONFIG_COMEDI_NI_6527=m CONFIG_COMEDI_NI_65XX=m CONFIG_COMEDI_NI_660X=m CONFIG_COMEDI_NI_670X=m CONFIG_COMEDI_NI_LABPC_PCI=m CONFIG_COMEDI_NI_PCIDIO=m CONFIG_COMEDI_NI_PCIMIO=m CONFIG_COMEDI_RTD520=m CONFIG_COMEDI_S626=m CONFIG_COMEDI_MITE=m CONFIG_COMEDI_NI_TIOCMD=m CONFIG_COMEDI_PCMCIA_DRIVERS=y CONFIG_COMEDI_CB_DAS16_CS=m CONFIG_COMEDI_DAS08_CS=m CONFIG_COMEDI_NI_DAQ_700_CS=m CONFIG_COMEDI_NI_DAQ_DIO24_CS=m CONFIG_COMEDI_NI_LABPC_CS=m CONFIG_COMEDI_NI_MIO_CS=m CONFIG_COMEDI_QUATECH_DAQP_CS=m CONFIG_COMEDI_USB_DRIVERS=y CONFIG_COMEDI_DT9812=m CONFIG_COMEDI_NI_USB6501=m CONFIG_COMEDI_USBDUX=m CONFIG_COMEDI_USBDUXFAST=m CONFIG_COMEDI_USBDUXSIGMA=m CONFIG_COMEDI_VMK80XX=m CONFIG_COMEDI_8255=m CONFIG_COMEDI_KCOMEDILIB=m CONFIG_COMEDI_FC=m CONFIG_COMEDI_AMPLC_DIO200=m CONFIG_COMEDI_AMPLC_PC236=m CONFIG_COMEDI_DAS08=m CONFIG_COMEDI_NI_LABPC=m CONFIG_COMEDI_NI_LABPC_ISADMA=m CONFIG_COMEDI_NI_TIO=m CONFIG_RTL8192U=m CONFIG_RTLLIB=m CONFIG_RTLLIB_CRYPTO_CCMP=m CONFIG_RTLLIB_CRYPTO_TKIP=m CONFIG_RTLLIB_CRYPTO_WEP=m CONFIG_RTL8192E=m CONFIG_R8712U=y CONFIG_R8188EU=y CONFIG_88EU_AP_MODE=y CONFIG_R8192EE=m CONFIG_R8723AU=y CONFIG_8723AU_AP_MODE=y CONFIG_8723AU_BT_COEXIST=y CONFIG_R8821AE=m CONFIG_RTS5208=y CONFIG_VT6655=m CONFIG_VT6656=m # # IIO staging drivers # # # Accelerometers # CONFIG_ADIS16201=y CONFIG_ADIS16203=y CONFIG_ADIS16204=y CONFIG_ADIS16209=y CONFIG_ADIS16220=y CONFIG_ADIS16240=y CONFIG_LIS3L02DQ=y CONFIG_SCA3000=y # # Analog to digital converters # CONFIG_AD7606=y CONFIG_AD7606_IFACE_PARALLEL=y CONFIG_AD7606_IFACE_SPI=y CONFIG_AD7780=y CONFIG_AD7816=y CONFIG_AD7192=y CONFIG_AD7280=y # # Analog digital bi-direction converters # CONFIG_ADT7316=y CONFIG_ADT7316_SPI=y CONFIG_ADT7316_I2C=y # # Capacitance to digital converters # CONFIG_AD7150=y CONFIG_AD7152=y CONFIG_AD7746=y # # Direct Digital Synthesis # CONFIG_AD9832=y CONFIG_AD9834=y # # Digital gyroscope sensors # CONFIG_ADIS16060=y # # Network Analyzer, Impedance Converters # CONFIG_AD5933=y # # Light sensors # CONFIG_SENSORS_ISL29018=y CONFIG_SENSORS_ISL29028=y CONFIG_TSL2583=y CONFIG_TSL2x7x=y # # Magnetometer sensors # CONFIG_SENSORS_HMC5843=y CONFIG_SENSORS_HMC5843_I2C=y CONFIG_SENSORS_HMC5843_SPI=y # # Active energy metering IC # CONFIG_ADE7753=y CONFIG_ADE7754=y CONFIG_ADE7758=y CONFIG_ADE7759=y CONFIG_ADE7854=y CONFIG_ADE7854_I2C=y CONFIG_ADE7854_SPI=y # # Resolver to digital converters # CONFIG_AD2S90=y CONFIG_AD2S1200=y CONFIG_AD2S1210=y # # Triggers - standalone # CONFIG_IIO_PERIODIC_RTC_TRIGGER=y CONFIG_IIO_DUMMY_EVGEN=y CONFIG_IIO_SIMPLE_DUMMY=y CONFIG_IIO_SIMPLE_DUMMY_EVENTS=y CONFIG_IIO_SIMPLE_DUMMY_BUFFER=y CONFIG_FB_XGI=y CONFIG_BCM_WIMAX=y CONFIG_FT1000=y CONFIG_FT1000_USB=y CONFIG_FT1000_PCMCIA=y # # Speakup console speech # CONFIG_SPEAKUP=y CONFIG_SPEAKUP_SYNTH_ACNTSA=y CONFIG_SPEAKUP_SYNTH_APOLLO=y CONFIG_SPEAKUP_SYNTH_AUDPTR=y CONFIG_SPEAKUP_SYNTH_BNS=y CONFIG_SPEAKUP_SYNTH_DECTLK=y CONFIG_SPEAKUP_SYNTH_DECEXT=y CONFIG_SPEAKUP_SYNTH_LTLK=y CONFIG_SPEAKUP_SYNTH_SOFT=y CONFIG_SPEAKUP_SYNTH_SPKOUT=y CONFIG_SPEAKUP_SYNTH_TXPRT=y CONFIG_SPEAKUP_SYNTH_DUMMY=y CONFIG_TOUCHSCREEN_CLEARPAD_TM1217=y CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4=y CONFIG_STAGING_MEDIA=y CONFIG_DVB_AS102=y CONFIG_I2C_BCM2048=y CONFIG_DVB_CXD2099=y CONFIG_VIDEO_DT3155=y CONFIG_DT3155_CCIR=y CONFIG_DT3155_STREAMING=y CONFIG_VIDEO_V4L2_INT_DEVICE=y CONFIG_VIDEO_TCM825X=y # # Android # CONFIG_ANDROID=y CONFIG_ANDROID_BINDER_IPC=y CONFIG_ASHMEM=y CONFIG_ANDROID_LOGGER=y CONFIG_ANDROID_TIMED_OUTPUT=y CONFIG_ANDROID_TIMED_GPIO=y # CONFIG_ANDROID_LOW_MEMORY_KILLER is not set CONFIG_ANDROID_INTF_ALARM_DEV=y CONFIG_SYNC=y CONFIG_SW_SYNC=y CONFIG_SW_SYNC_USER=y # CONFIG_ION is not set CONFIG_USB_WPAN_HCD=y CONFIG_WIMAX_GDM72XX=y CONFIG_WIMAX_GDM72XX_QOS=y CONFIG_WIMAX_GDM72XX_K_MODE=y CONFIG_WIMAX_GDM72XX_WIMAX2=y CONFIG_WIMAX_GDM72XX_USB=y # CONFIG_WIMAX_GDM72XX_SDIO is not set CONFIG_WIMAX_GDM72XX_USB_PM=y CONFIG_LTE_GDM724X=m CONFIG_FIREWIRE_SERIAL=y CONFIG_FWTTY_MAX_TOTAL_PORTS=64 CONFIG_FWTTY_MAX_CARD_PORTS=32 CONFIG_MTD_SPINAND_MT29F=y CONFIG_MTD_SPINAND_ONDIEECC=y CONFIG_LUSTRE_FS=m CONFIG_LUSTRE_OBD_MAX_IOCTL_BUFFER=8192 CONFIG_LUSTRE_DEBUG_EXPENSIVE_CHECK=y CONFIG_LUSTRE_LLITE_LLOOP=m CONFIG_LNET=m CONFIG_LNET_MAX_PAYLOAD=1048576 CONFIG_LNET_SELFTEST=m CONFIG_LNET_XPRT_IB=m CONFIG_XILLYBUS=y CONFIG_XILLYBUS_PCIE=y CONFIG_DGNC=y CONFIG_DGAP=y CONFIG_GS_FPGABOOT=y CONFIG_CRYPTO_SKEIN=y CONFIG_CRYPTO_THREEFISH=y CONFIG_UNISYSSPAR=y CONFIG_UNISYS_VISORUTIL=y CONFIG_UNISYS_VISORCHANNEL=y CONFIG_UNISYS_VISORCHIPSET=y CONFIG_UNISYS_CHANNELSTUB=y CONFIG_UNISYS_UISLIB=y CONFIG_UNISYS_VIRTPCI=y CONFIG_UNISYS_VIRTHBA=y CONFIG_X86_PLATFORM_DEVICES=y CONFIG_ACER_WMI=y CONFIG_ACERHDF=y CONFIG_ALIENWARE_WMI=y CONFIG_ASUS_LAPTOP=y CONFIG_DELL_LAPTOP=y CONFIG_DELL_WMI=y CONFIG_DELL_WMI_AIO=y CONFIG_DELL_SMO8800=y CONFIG_FUJITSU_LAPTOP=y CONFIG_FUJITSU_LAPTOP_DEBUG=y CONFIG_FUJITSU_TABLET=y CONFIG_AMILO_RFKILL=y CONFIG_HP_ACCEL=y CONFIG_HP_WIRELESS=y CONFIG_HP_WMI=y CONFIG_MSI_LAPTOP=y CONFIG_PANASONIC_LAPTOP=y CONFIG_COMPAL_LAPTOP=y CONFIG_SONY_LAPTOP=y CONFIG_SONYPI_COMPAT=y CONFIG_IDEAPAD_LAPTOP=y CONFIG_THINKPAD_ACPI=y CONFIG_THINKPAD_ACPI_DEBUGFACILITIES=y CONFIG_THINKPAD_ACPI_DEBUG=y CONFIG_THINKPAD_ACPI_UNSAFE_LEDS=y CONFIG_THINKPAD_ACPI_VIDEO=y CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y CONFIG_SENSORS_HDAPS=y CONFIG_INTEL_MENLOW=y CONFIG_EEEPC_LAPTOP=y CONFIG_ASUS_WMI=y CONFIG_ASUS_NB_WMI=y CONFIG_EEEPC_WMI=y CONFIG_ACPI_WMI=y CONFIG_MSI_WMI=y CONFIG_TOPSTAR_LAPTOP=y CONFIG_ACPI_TOSHIBA=y CONFIG_TOSHIBA_BT_RFKILL=y CONFIG_TOSHIBA_HAPS=y CONFIG_ACPI_CMPC=y CONFIG_INTEL_IPS=y CONFIG_IBM_RTL=y CONFIG_SAMSUNG_LAPTOP=y CONFIG_MXM_WMI=y CONFIG_INTEL_OAKTRAIL=y CONFIG_SAMSUNG_Q10=y CONFIG_APPLE_GMUX=y CONFIG_INTEL_RST=y CONFIG_INTEL_SMARTCONNECT=y CONFIG_PVPANIC=y CONFIG_CHROME_PLATFORMS=y CONFIG_CHROMEOS_LAPTOP=y CONFIG_CHROMEOS_PSTORE=y # # SOC (System On Chip) specific Drivers # CONFIG_CLKDEV_LOOKUP=y CONFIG_HAVE_CLK_PREPARE=y CONFIG_COMMON_CLK=y # # Common Clock Framework # CONFIG_COMMON_CLK_WM831X=y CONFIG_COMMON_CLK_MAX77686=y CONFIG_COMMON_CLK_SI5351=y CONFIG_COMMON_CLK_S2MPS11=y CONFIG_CLK_TWL6040=y CONFIG_COMMON_CLK_PALMAS=y # # Hardware Spinlock drivers # # # Clock Source drivers # CONFIG_CLKEVT_I8253=y CONFIG_I8253_LOCK=y CONFIG_CLKBLD_I8253=y # CONFIG_SH_TIMER_CMT is not set # CONFIG_SH_TIMER_MTU2 is not set # CONFIG_SH_TIMER_TMU is not set # CONFIG_EM_TIMER_STI is not set CONFIG_MAILBOX=y CONFIG_IOMMU_API=y CONFIG_IOMMU_SUPPORT=y CONFIG_AMD_IOMMU=y CONFIG_AMD_IOMMU_STATS=y CONFIG_AMD_IOMMU_V2=y CONFIG_DMAR_TABLE=y CONFIG_INTEL_IOMMU=y CONFIG_INTEL_IOMMU_DEFAULT_ON=y CONFIG_INTEL_IOMMU_FLOPPY_WA=y CONFIG_IRQ_REMAP=y # # Remoteproc drivers # CONFIG_REMOTEPROC=y CONFIG_STE_MODEM_RPROC=y # # Rpmsg drivers # CONFIG_PM_DEVFREQ=y # # DEVFREQ Governors # CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=y CONFIG_DEVFREQ_GOV_PERFORMANCE=y CONFIG_DEVFREQ_GOV_POWERSAVE=y CONFIG_DEVFREQ_GOV_USERSPACE=y # # DEVFREQ Drivers # CONFIG_EXTCON=y # # Extcon Device Drivers # CONFIG_EXTCON_ADC_JACK=y CONFIG_EXTCON_GPIO=y CONFIG_EXTCON_MAX14577=y CONFIG_EXTCON_MAX77693=y CONFIG_EXTCON_MAX8997=y CONFIG_EXTCON_PALMAS=y CONFIG_EXTCON_SM5502=y CONFIG_MEMORY=y CONFIG_IIO=y CONFIG_IIO_BUFFER=y CONFIG_IIO_BUFFER_CB=y CONFIG_IIO_KFIFO_BUF=y CONFIG_IIO_TRIGGERED_BUFFER=y CONFIG_IIO_TRIGGER=y CONFIG_IIO_CONSUMERS_PER_TRIGGER=2 # # Accelerometers # CONFIG_BMA180=y CONFIG_BMC150_ACCEL=y CONFIG_HID_SENSOR_ACCEL_3D=y CONFIG_IIO_ST_ACCEL_3AXIS=y CONFIG_IIO_ST_ACCEL_I2C_3AXIS=y CONFIG_IIO_ST_ACCEL_SPI_3AXIS=y CONFIG_KXSD9=y CONFIG_MMA8452=y CONFIG_KXCJK1013=y # # Analog to digital converters # CONFIG_AD_SIGMA_DELTA=y CONFIG_AD7266=y CONFIG_AD7291=y CONFIG_AD7298=y CONFIG_AD7476=y CONFIG_AD7791=y CONFIG_AD7793=y CONFIG_AD7887=y CONFIG_AD7923=y CONFIG_AD799X=y CONFIG_LP8788_ADC=y CONFIG_MAX1027=y CONFIG_MAX1363=y CONFIG_MCP320X=y CONFIG_MCP3422=y CONFIG_MEN_Z188_ADC=y CONFIG_NAU7802=y CONFIG_TI_ADC081C=y CONFIG_TI_ADC128S052=y CONFIG_TI_AM335X_ADC=y CONFIG_TWL4030_MADC=y CONFIG_TWL6030_GPADC=y CONFIG_VIPERBOARD_ADC=y # # Amplifiers # CONFIG_AD8366=y # # Hid Sensor IIO Common # CONFIG_HID_SENSOR_IIO_COMMON=y CONFIG_HID_SENSOR_IIO_TRIGGER=y CONFIG_IIO_ST_SENSORS_I2C=y CONFIG_IIO_ST_SENSORS_SPI=y CONFIG_IIO_ST_SENSORS_CORE=y # # Digital to analog converters # CONFIG_AD5064=y CONFIG_AD5360=y CONFIG_AD5380=y CONFIG_AD5421=y CONFIG_AD5446=y CONFIG_AD5449=y CONFIG_AD5504=y CONFIG_AD5624R_SPI=y CONFIG_AD5686=y CONFIG_AD5755=y CONFIG_AD5764=y CONFIG_AD5791=y CONFIG_AD7303=y CONFIG_MAX517=y CONFIG_MCP4725=y CONFIG_MCP4922=y # # Frequency Synthesizers DDS/PLL # # # Clock Generator/Distribution # CONFIG_AD9523=y # # Phase-Locked Loop (PLL) frequency synthesizers # CONFIG_ADF4350=y # # Digital gyroscope sensors # CONFIG_ADIS16080=y CONFIG_ADIS16130=y CONFIG_ADIS16136=y CONFIG_ADIS16260=y CONFIG_ADXRS450=y CONFIG_HID_SENSOR_GYRO_3D=y CONFIG_IIO_ST_GYRO_3AXIS=y CONFIG_IIO_ST_GYRO_I2C_3AXIS=y CONFIG_IIO_ST_GYRO_SPI_3AXIS=y CONFIG_ITG3200=y # # Humidity sensors # CONFIG_DHT11=y CONFIG_SI7005=y # # Inertial measurement units # CONFIG_ADIS16400=y CONFIG_ADIS16480=y CONFIG_INV_MPU6050_IIO=y CONFIG_IIO_ADIS_LIB=y CONFIG_IIO_ADIS_LIB_BUFFER=y # # Light sensors # CONFIG_ADJD_S311=y CONFIG_APDS9300=y CONFIG_CM32181=y CONFIG_CM36651=y CONFIG_GP2AP020A00F=y CONFIG_ISL29125=y CONFIG_HID_SENSOR_ALS=y CONFIG_HID_SENSOR_PROX=y CONFIG_SENSORS_LM3533=y CONFIG_LTR501=y CONFIG_TCS3414=y CONFIG_TCS3472=y CONFIG_SENSORS_TSL2563=y CONFIG_TSL4531=y CONFIG_VCNL4000=y # # Magnetometer sensors # CONFIG_AK8975=y CONFIG_AK09911=y CONFIG_MAG3110=y CONFIG_HID_SENSOR_MAGNETOMETER_3D=y CONFIG_IIO_ST_MAGN_3AXIS=y CONFIG_IIO_ST_MAGN_I2C_3AXIS=y CONFIG_IIO_ST_MAGN_SPI_3AXIS=y # # Inclinometer sensors # CONFIG_HID_SENSOR_INCLINOMETER_3D=y CONFIG_HID_SENSOR_DEVICE_ROTATION=y # # Triggers - standalone # CONFIG_IIO_INTERRUPT_TRIGGER=y CONFIG_IIO_SYSFS_TRIGGER=y # # Pressure sensors # CONFIG_HID_SENSOR_PRESS=y CONFIG_MPL115=y CONFIG_MPL3115=y CONFIG_IIO_ST_PRESS=y CONFIG_IIO_ST_PRESS_I2C=y CONFIG_IIO_ST_PRESS_SPI=y CONFIG_T5403=y # # Lightning sensors # CONFIG_AS3935=y # # Temperature sensors # CONFIG_MLX90614=y CONFIG_TMP006=y CONFIG_NTB=y CONFIG_VME_BUS=y # # VME Bridge Drivers # CONFIG_VME_CA91CX42=y CONFIG_VME_TSI148=y # # VME Board Drivers # CONFIG_VMIVME_7805=y # # VME Device Drivers # CONFIG_VME_USER=y CONFIG_VME_PIO2=y CONFIG_PWM=y CONFIG_PWM_SYSFS=y CONFIG_PWM_LP3943=y CONFIG_PWM_LPSS=y CONFIG_PWM_LPSS_PCI=y CONFIG_PWM_LPSS_PLATFORM=y CONFIG_PWM_TWL=y CONFIG_PWM_TWL_LED=y CONFIG_IPACK_BUS=y CONFIG_BOARD_TPCI200=y CONFIG_SERIAL_IPOCTAL=y CONFIG_RESET_CONTROLLER=y CONFIG_FMC=y CONFIG_FMC_FAKEDEV=y CONFIG_FMC_TRIVIAL=y CONFIG_FMC_WRITE_EEPROM=y CONFIG_FMC_CHARDEV=y # # PHY Subsystem # CONFIG_GENERIC_PHY=y CONFIG_BCM_KONA_USB2_PHY=y CONFIG_PHY_SAMSUNG_USB2=y # CONFIG_PHY_EXYNOS4210_USB2 is not set # CONFIG_PHY_EXYNOS4X12_USB2 is not set # CONFIG_PHY_EXYNOS5250_USB2 is not set CONFIG_PHY_ST_SPEAR1310_MIPHY=y CONFIG_PHY_ST_SPEAR1340_MIPHY=y CONFIG_POWERCAP=y CONFIG_INTEL_RAPL=y CONFIG_MCB=y CONFIG_MCB_PCI=y CONFIG_RAS=y CONFIG_THUNDERBOLT=y # # Firmware Drivers # CONFIG_EDD=y # CONFIG_EDD_OFF is not set CONFIG_FIRMWARE_MEMMAP=y CONFIG_DELL_RBU=y CONFIG_DCDBAS=y CONFIG_DMIID=y CONFIG_DMI_SYSFS=y CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y CONFIG_ISCSI_IBFT_FIND=y CONFIG_ISCSI_IBFT=y CONFIG_GOOGLE_FIRMWARE=y # # Google Firmware Drivers # CONFIG_GOOGLE_SMI=y CONFIG_GOOGLE_MEMCONSOLE=y # # EFI (Extensible Firmware Interface) Support # CONFIG_EFI_VARS=y CONFIG_EFI_VARS_PSTORE=y CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE=y CONFIG_EFI_RUNTIME_MAP=y CONFIG_EFI_RUNTIME_WRAPPERS=y CONFIG_UEFI_CPER=y # # File systems # CONFIG_DCACHE_WORD_ACCESS=y CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT2_FS_XIP=y CONFIG_EXT3_FS=y CONFIG_EXT3_DEFAULTS_TO_ORDERED=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y CONFIG_EXT4_DEBUG=y CONFIG_FS_XIP=y CONFIG_JBD=y CONFIG_JBD_DEBUG=y CONFIG_JBD2=y CONFIG_JBD2_DEBUG=y CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=y CONFIG_REISERFS_CHECK=y CONFIG_REISERFS_PROC_INFO=y CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=y CONFIG_JFS_POSIX_ACL=y CONFIG_JFS_SECURITY=y CONFIG_JFS_DEBUG=y CONFIG_JFS_STATISTICS=y CONFIG_XFS_FS=y CONFIG_XFS_QUOTA=y CONFIG_XFS_POSIX_ACL=y CONFIG_XFS_RT=y CONFIG_XFS_DEBUG=y CONFIG_GFS2_FS=y CONFIG_GFS2_FS_LOCKING_DLM=y CONFIG_OCFS2_FS=y CONFIG_OCFS2_FS_O2CB=y CONFIG_OCFS2_FS_USERSPACE_CLUSTER=y CONFIG_OCFS2_FS_STATS=y CONFIG_OCFS2_DEBUG_MASKLOG=y CONFIG_OCFS2_DEBUG_FS=y CONFIG_BTRFS_FS=y CONFIG_BTRFS_FS_POSIX_ACL=y CONFIG_BTRFS_FS_CHECK_INTEGRITY=y CONFIG_BTRFS_FS_RUN_SANITY_TESTS=y CONFIG_BTRFS_DEBUG=y CONFIG_BTRFS_ASSERT=y CONFIG_NILFS2_FS=y CONFIG_FS_POSIX_ACL=y CONFIG_EXPORTFS=y CONFIG_FILE_LOCKING=y CONFIG_FSNOTIFY=y CONFIG_DNOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_FANOTIFY=y CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y CONFIG_QUOTA=y CONFIG_QUOTA_NETLINK_INTERFACE=y # CONFIG_PRINT_QUOTA_WARNING is not set CONFIG_QUOTA_DEBUG=y CONFIG_QUOTA_TREE=y CONFIG_QFMT_V1=y CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y CONFIG_QUOTACTL_COMPAT=y CONFIG_AUTOFS4_FS=y CONFIG_FUSE_FS=y CONFIG_CUSE=y # # Caches # CONFIG_FSCACHE=y CONFIG_FSCACHE_STATS=y CONFIG_FSCACHE_HISTOGRAM=y CONFIG_FSCACHE_DEBUG=y CONFIG_FSCACHE_OBJECT_LIST=y CONFIG_CACHEFILES=y CONFIG_CACHEFILES_DEBUG=y CONFIG_CACHEFILES_HISTOGRAM=y # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=y CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=y CONFIG_NTFS_DEBUG=y CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_KERNFS=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_TMPFS_XATTR=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_CONFIGFS_FS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_ADFS_FS=y CONFIG_ADFS_FS_RW=y CONFIG_AFFS_FS=y CONFIG_ECRYPT_FS=y CONFIG_ECRYPT_FS_MESSAGING=y CONFIG_HFS_FS=y CONFIG_HFSPLUS_FS=y CONFIG_HFSPLUS_FS_POSIX_ACL=y CONFIG_BEFS_FS=y CONFIG_BEFS_DEBUG=y CONFIG_BFS_FS=y CONFIG_EFS_FS=y CONFIG_JFFS2_FS=y CONFIG_JFFS2_FS_DEBUG=0 CONFIG_JFFS2_FS_WRITEBUFFER=y CONFIG_JFFS2_FS_WBUF_VERIFY=y CONFIG_JFFS2_SUMMARY=y CONFIG_JFFS2_FS_XATTR=y CONFIG_JFFS2_FS_POSIX_ACL=y CONFIG_JFFS2_FS_SECURITY=y CONFIG_JFFS2_COMPRESSION_OPTIONS=y CONFIG_JFFS2_ZLIB=y CONFIG_JFFS2_LZO=y CONFIG_JFFS2_RTIME=y CONFIG_JFFS2_RUBIN=y # CONFIG_JFFS2_CMODE_NONE is not set CONFIG_JFFS2_CMODE_PRIORITY=y # CONFIG_JFFS2_CMODE_SIZE is not set # CONFIG_JFFS2_CMODE_FAVOURLZO is not set CONFIG_UBIFS_FS=y CONFIG_UBIFS_FS_ADVANCED_COMPR=y CONFIG_UBIFS_FS_LZO=y CONFIG_UBIFS_FS_ZLIB=y CONFIG_LOGFS=y CONFIG_CRAMFS=y CONFIG_SQUASHFS=y CONFIG_SQUASHFS_FILE_CACHE=y # CONFIG_SQUASHFS_FILE_DIRECT is not set # CONFIG_SQUASHFS_DECOMP_SINGLE is not set # CONFIG_SQUASHFS_DECOMP_MULTI is not set CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU=y CONFIG_SQUASHFS_XATTR=y CONFIG_SQUASHFS_ZLIB=y CONFIG_SQUASHFS_LZO=y CONFIG_SQUASHFS_XZ=y CONFIG_SQUASHFS_4K_DEVBLK_SIZE=y CONFIG_SQUASHFS_EMBEDDED=y CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3 CONFIG_VXFS_FS=y CONFIG_MINIX_FS=y CONFIG_OMFS_FS=y CONFIG_HPFS_FS=y CONFIG_QNX4FS_FS=y CONFIG_QNX6FS_FS=y CONFIG_QNX6FS_DEBUG=y CONFIG_ROMFS_FS=y # CONFIG_ROMFS_BACKED_BY_BLOCK is not set # CONFIG_ROMFS_BACKED_BY_MTD is not set CONFIG_ROMFS_BACKED_BY_BOTH=y CONFIG_ROMFS_ON_BLOCK=y CONFIG_ROMFS_ON_MTD=y CONFIG_PSTORE=y CONFIG_PSTORE_CONSOLE=y # CONFIG_PSTORE_FTRACE is not set CONFIG_PSTORE_RAM=y CONFIG_SYSV_FS=y CONFIG_UFS_FS=y CONFIG_UFS_FS_WRITE=y CONFIG_UFS_DEBUG=y CONFIG_EXOFS_FS=y CONFIG_EXOFS_DEBUG=y CONFIG_F2FS_FS=y CONFIG_F2FS_STAT_FS=y CONFIG_F2FS_FS_XATTR=y CONFIG_F2FS_FS_POSIX_ACL=y CONFIG_F2FS_FS_SECURITY=y CONFIG_F2FS_CHECK_FS=y CONFIG_EFIVAR_FS=y CONFIG_ORE=y CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=y CONFIG_NFS_V2=y CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_NFS_SWAP=y CONFIG_NFS_V4_1=y CONFIG_NFS_V4_2=y CONFIG_PNFS_FILE_LAYOUT=y CONFIG_PNFS_BLOCK=y CONFIG_PNFS_OBJLAYOUT=y CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="y" CONFIG_NFS_V4_1_MIGRATION=y CONFIG_NFS_V4_SECURITY_LABEL=y CONFIG_ROOT_NFS=y CONFIG_NFS_FSCACHE=y CONFIG_NFS_USE_LEGACY_DNS=y CONFIG_NFS_DEBUG=y CONFIG_NFSD=y CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_NFSD_V4_SECURITY_LABEL=y CONFIG_NFSD_FAULT_INJECTION=y CONFIG_GRACE_PERIOD=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_NFS_ACL_SUPPORT=y CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y CONFIG_SUNRPC_GSS=y CONFIG_SUNRPC_BACKCHANNEL=y CONFIG_SUNRPC_SWAP=y CONFIG_RPCSEC_GSS_KRB5=y CONFIG_SUNRPC_DEBUG=y CONFIG_SUNRPC_XPRT_RDMA_CLIENT=y CONFIG_SUNRPC_XPRT_RDMA_SERVER=y CONFIG_CEPH_FS=y CONFIG_CEPH_FSCACHE=y CONFIG_CEPH_FS_POSIX_ACL=y CONFIG_CIFS=y CONFIG_CIFS_STATS=y CONFIG_CIFS_STATS2=y CONFIG_CIFS_WEAK_PW_HASH=y CONFIG_CIFS_UPCALL=y CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y CONFIG_CIFS_ACL=y CONFIG_CIFS_DEBUG=y CONFIG_CIFS_DEBUG2=y CONFIG_CIFS_DFS_UPCALL=y CONFIG_CIFS_SMB2=y CONFIG_CIFS_FSCACHE=y CONFIG_NCP_FS=y CONFIG_NCPFS_PACKET_SIGNING=y CONFIG_NCPFS_IOCTL_LOCKING=y CONFIG_NCPFS_STRONG=y CONFIG_NCPFS_NFS_NS=y CONFIG_NCPFS_OS2_NS=y CONFIG_NCPFS_SMALLDOS=y CONFIG_NCPFS_NLS=y CONFIG_NCPFS_EXTRAS=y CONFIG_CODA_FS=y CONFIG_AFS_FS=y CONFIG_AFS_DEBUG=y CONFIG_AFS_FSCACHE=y CONFIG_9P_FS=y CONFIG_9P_FSCACHE=y CONFIG_9P_FS_POSIX_ACL=y CONFIG_9P_FS_SECURITY=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_737=y CONFIG_NLS_CODEPAGE_775=y CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_CODEPAGE_852=y CONFIG_NLS_CODEPAGE_855=y CONFIG_NLS_CODEPAGE_857=y CONFIG_NLS_CODEPAGE_860=y CONFIG_NLS_CODEPAGE_861=y CONFIG_NLS_CODEPAGE_862=y CONFIG_NLS_CODEPAGE_863=y CONFIG_NLS_CODEPAGE_864=y CONFIG_NLS_CODEPAGE_865=y CONFIG_NLS_CODEPAGE_866=y CONFIG_NLS_CODEPAGE_869=y CONFIG_NLS_CODEPAGE_936=y CONFIG_NLS_CODEPAGE_950=y CONFIG_NLS_CODEPAGE_932=y CONFIG_NLS_CODEPAGE_949=y CONFIG_NLS_CODEPAGE_874=y CONFIG_NLS_ISO8859_8=y CONFIG_NLS_CODEPAGE_1250=y CONFIG_NLS_CODEPAGE_1251=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_ISO8859_2=y CONFIG_NLS_ISO8859_3=y CONFIG_NLS_ISO8859_4=y CONFIG_NLS_ISO8859_5=y CONFIG_NLS_ISO8859_6=y CONFIG_NLS_ISO8859_7=y CONFIG_NLS_ISO8859_9=y CONFIG_NLS_ISO8859_13=y CONFIG_NLS_ISO8859_14=y CONFIG_NLS_ISO8859_15=y CONFIG_NLS_KOI8_R=y CONFIG_NLS_KOI8_U=y CONFIG_NLS_MAC_ROMAN=y CONFIG_NLS_MAC_CELTIC=y CONFIG_NLS_MAC_CENTEURO=y CONFIG_NLS_MAC_CROATIAN=y CONFIG_NLS_MAC_CYRILLIC=y CONFIG_NLS_MAC_GAELIC=y CONFIG_NLS_MAC_GREEK=y CONFIG_NLS_MAC_ICELAND=y CONFIG_NLS_MAC_INUIT=y CONFIG_NLS_MAC_ROMANIAN=y CONFIG_NLS_MAC_TURKISH=y CONFIG_NLS_UTF8=y CONFIG_DLM=y CONFIG_DLM_DEBUG=y # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # # printk and dmesg options # CONFIG_PRINTK_TIME=y CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4 # CONFIG_BOOT_PRINTK_DELAY is not set CONFIG_DYNAMIC_DEBUG=y # # Compile-time checks and compiler options # CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_INFO_REDUCED is not set # CONFIG_DEBUG_INFO_SPLIT is not set CONFIG_DEBUG_INFO_DWARF4=y CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=2048 CONFIG_STRIP_ASM_SYMS=y CONFIG_READABLE_ASM=y CONFIG_UNUSED_SYMBOLS=y CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_SECTION_MISMATCH=y CONFIG_ARCH_WANT_FRAME_POINTERS=y CONFIG_FRAME_POINTER=y CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y CONFIG_MAGIC_SYSRQ=y CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1 CONFIG_DEBUG_KERNEL=y # # Memory Debugging # CONFIG_DEBUG_PAGEALLOC=y CONFIG_WANT_PAGE_DEBUG_FLAGS=y CONFIG_PAGE_GUARD=y CONFIG_DEBUG_OBJECTS=y CONFIG_DEBUG_OBJECTS_SELFTEST=y CONFIG_DEBUG_OBJECTS_FREE=y CONFIG_DEBUG_OBJECTS_TIMERS=y CONFIG_DEBUG_OBJECTS_WORK=y CONFIG_DEBUG_OBJECTS_RCU_HEAD=y CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER=y CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1 # CONFIG_SLUB_DEBUG_ON is not set CONFIG_SLUB_STATS=y CONFIG_HAVE_DEBUG_KMEMLEAK=y CONFIG_DEBUG_KMEMLEAK=y CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400 # CONFIG_DEBUG_KMEMLEAK_TEST is not set # CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set CONFIG_DEBUG_STACK_USAGE=y CONFIG_DEBUG_VM=y CONFIG_DEBUG_VM_VMACACHE=y CONFIG_DEBUG_VM_RB=y CONFIG_DEBUG_VIRTUAL=y CONFIG_DEBUG_MEMORY_INIT=y CONFIG_MEMORY_NOTIFIER_ERROR_INJECT=y CONFIG_DEBUG_PER_CPU_MAPS=y CONFIG_HAVE_DEBUG_STACKOVERFLOW=y CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_HAVE_ARCH_KMEMCHECK=y CONFIG_HAVE_ARCH_KASAN=y CONFIG_KASAN=y CONFIG_KASAN_SANITIZE_ALL=y CONFIG_DEBUG_SHIRQ=y # # Debug Lockups and Hangs # CONFIG_LOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR=y CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1 CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1 # CONFIG_DETECT_HUNG_TASK is not set # CONFIG_PANIC_ON_OOPS is not set CONFIG_PANIC_ON_OOPS_VALUE=0 CONFIG_PANIC_TIMEOUT=0 CONFIG_SCHED_DEBUG=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_DEBUG_PREEMPT=y # # Lock Debugging (spinlocks, mutexes, etc...) # CONFIG_DEBUG_RT_MUTEXES=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_PROVE_LOCKING=y CONFIG_LOCKDEP=y CONFIG_LOCK_STAT=y CONFIG_DEBUG_LOCKDEP=y CONFIG_DEBUG_ATOMIC_SLEEP=y CONFIG_DEBUG_LOCKING_API_SELFTESTS=y # CONFIG_LOCK_TORTURE_TEST is not set CONFIG_TRACE_IRQFLAGS=y CONFIG_STACKTRACE=y CONFIG_DEBUG_KOBJECT=y CONFIG_DEBUG_KOBJECT_RELEASE=y CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_LIST=y CONFIG_DEBUG_PI_LIST=y CONFIG_DEBUG_SG=y CONFIG_DEBUG_NOTIFIERS=y CONFIG_DEBUG_CREDENTIALS=y # # RCU Debugging # CONFIG_PROVE_RCU=y CONFIG_PROVE_RCU_REPEATEDLY=y CONFIG_SPARSE_RCU_POINTER=y CONFIG_TORTURE_TEST=m CONFIG_RCU_TORTURE_TEST=m CONFIG_RCU_CPU_STALL_TIMEOUT=200 CONFIG_RCU_CPU_STALL_INFO=y CONFIG_RCU_TRACE=y CONFIG_DEBUG_BLOCK_EXT_DEVT=y CONFIG_NOTIFIER_ERROR_INJECTION=y CONFIG_CPU_NOTIFIER_ERROR_INJECT=y CONFIG_PM_NOTIFIER_ERROR_INJECT=y CONFIG_FAULT_INJECTION=y CONFIG_FAILSLAB=y CONFIG_FAIL_PAGE_ALLOC=y CONFIG_FAIL_MAKE_REQUEST=y CONFIG_FAIL_IO_TIMEOUT=y CONFIG_FAIL_MMC_REQUEST=y CONFIG_FAULT_INJECTION_DEBUG_FS=y CONFIG_LATENCYTOP=y CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS=y CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y CONFIG_USER_STACKTRACE_SUPPORT=y CONFIG_NOP_TRACER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HAVE_FENTRY=y CONFIG_HAVE_C_RECORDMCOUNT=y CONFIG_TRACER_MAX_TRACE=y CONFIG_TRACE_CLOCK=y CONFIG_RING_BUFFER=y CONFIG_EVENT_TRACING=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_RING_BUFFER_ALLOW_SWAP=y CONFIG_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_TRACING_SUPPORT=y CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y CONFIG_IRQSOFF_TRACER=y CONFIG_PREEMPT_TRACER=y CONFIG_SCHED_TRACER=y CONFIG_FTRACE_SYSCALLS=y CONFIG_TRACER_SNAPSHOT=y CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP=y CONFIG_BRANCH_PROFILE_NONE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set # CONFIG_PROFILE_ALL_BRANCHES is not set CONFIG_STACK_TRACER=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_KPROBE_EVENT=y CONFIG_UPROBE_EVENT=y CONFIG_PROBE_EVENTS=y CONFIG_DYNAMIC_FTRACE=y CONFIG_DYNAMIC_FTRACE_WITH_REGS=y CONFIG_FUNCTION_PROFILER=y CONFIG_FTRACE_MCOUNT_RECORD=y # CONFIG_FTRACE_STARTUP_TEST is not set CONFIG_MMIOTRACE=y CONFIG_MMIOTRACE_TEST=m CONFIG_TRACEPOINT_BENCHMARK=y # CONFIG_RING_BUFFER_BENCHMARK is not set # CONFIG_RING_BUFFER_STARTUP_TEST is not set # # Runtime Testing # CONFIG_LKDTM=y CONFIG_TEST_LIST_SORT=y # CONFIG_KPROBES_SANITY_TEST is not set CONFIG_BACKTRACE_SELF_TEST=y CONFIG_RBTREE_TEST=y CONFIG_INTERVAL_TREE_TEST=m CONFIG_PERCPU_TEST=m CONFIG_ATOMIC64_SELFTEST=y CONFIG_ASYNC_RAID6_TEST=y CONFIG_TEST_STRING_HELPERS=y CONFIG_TEST_KSTRTOX=y CONFIG_TEST_RHASHTABLE=y CONFIG_PROVIDE_OHCI1394_DMA_INIT=y CONFIG_DMA_API_DEBUG=y CONFIG_TEST_MODULE=m CONFIG_TEST_USER_COPY=m CONFIG_TEST_BPF=m CONFIG_TEST_FIRMWARE=y # CONFIG_TEST_UDELAY is not set CONFIG_SAMPLES=y CONFIG_SAMPLE_TRACE_EVENTS=m CONFIG_SAMPLE_KOBJECT=m CONFIG_SAMPLE_KPROBES=m CONFIG_SAMPLE_KRETPROBES=m CONFIG_SAMPLE_HW_BREAKPOINT=m CONFIG_SAMPLE_KFIFO=m CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set # CONFIG_STRICT_DEVMEM is not set CONFIG_X86_VERBOSE_BOOTUP=y CONFIG_EARLY_PRINTK=y CONFIG_EARLY_PRINTK_DBGP=y CONFIG_EARLY_PRINTK_EFI=y CONFIG_X86_PTDUMP=y CONFIG_EFI_PGT_DUMP=y CONFIG_DEBUG_RODATA=y CONFIG_DEBUG_RODATA_TEST=y CONFIG_DEBUG_SET_MODULE_RONX=y CONFIG_DEBUG_NX_TEST=m CONFIG_DOUBLEFAULT=y CONFIG_DEBUG_TLBFLUSH=y CONFIG_IOMMU_DEBUG=y CONFIG_IOMMU_STRESS=y CONFIG_IOMMU_LEAK=y CONFIG_HAVE_MMIOTRACE_SUPPORT=y # CONFIG_X86_DECODER_SELFTEST is not set CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 CONFIG_DEBUG_BOOT_PARAMS=y CONFIG_CPA_DEBUG=y CONFIG_OPTIMIZE_INLINING=y CONFIG_DEBUG_NMI_SELFTEST=y CONFIG_X86_DEBUG_STATIC_CPU_HAS=y # # Security options # CONFIG_KEYS=y CONFIG_PERSISTENT_KEYRINGS=y CONFIG_BIG_KEYS=y CONFIG_TRUSTED_KEYS=y CONFIG_ENCRYPTED_KEYS=y CONFIG_KEYS_DEBUG_PROC_KEYS=y CONFIG_SECURITY_DMESG_RESTRICT=y CONFIG_SECURITY=y CONFIG_SECURITYFS=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_NETWORK_XFRM=y CONFIG_SECURITY_PATH=y CONFIG_INTEL_TXT=y CONFIG_LSM_MMAP_MIN_ADDR=65536 CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX=y CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX_VALUE=19 CONFIG_SECURITY_SMACK=y CONFIG_SECURITY_TOMOYO=y CONFIG_SECURITY_TOMOYO_MAX_ACCEPT_ENTRY=2048 CONFIG_SECURITY_TOMOYO_MAX_AUDIT_LOG=1024 CONFIG_SECURITY_TOMOYO_OMIT_USERSPACE_LOADER=y CONFIG_SECURITY_APPARMOR=y CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1 CONFIG_SECURITY_APPARMOR_HASH=y CONFIG_SECURITY_YAMA=y CONFIG_SECURITY_YAMA_STACKED=y CONFIG_INTEGRITY=y CONFIG_INTEGRITY_SIGNATURE=y CONFIG_INTEGRITY_AUDIT=y CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y CONFIG_IMA=y CONFIG_IMA_MEASURE_PCR_IDX=10 CONFIG_IMA_LSM_RULES=y # CONFIG_IMA_TEMPLATE is not set # CONFIG_IMA_NG_TEMPLATE is not set CONFIG_IMA_SIG_TEMPLATE=y CONFIG_IMA_DEFAULT_TEMPLATE="ima-sig" # CONFIG_IMA_DEFAULT_HASH_SHA1 is not set # CONFIG_IMA_DEFAULT_HASH_SHA256 is not set # CONFIG_IMA_DEFAULT_HASH_SHA512 is not set CONFIG_IMA_DEFAULT_HASH_WP512=y CONFIG_IMA_DEFAULT_HASH="wp512" CONFIG_IMA_APPRAISE=y # CONFIG_IMA_TRUSTED_KEYRING is not set CONFIG_EVM=y # # EVM options # CONFIG_EVM_ATTR_FSUUID=y CONFIG_EVM_EXTRA_SMACK_XATTRS=y # CONFIG_DEFAULT_SECURITY_SELINUX is not set # CONFIG_DEFAULT_SECURITY_SMACK is not set # CONFIG_DEFAULT_SECURITY_TOMOYO is not set # CONFIG_DEFAULT_SECURITY_APPARMOR is not set # CONFIG_DEFAULT_SECURITY_YAMA is not set CONFIG_DEFAULT_SECURITY_DAC=y CONFIG_DEFAULT_SECURITY="" CONFIG_XOR_BLOCKS=y CONFIG_ASYNC_CORE=y CONFIG_ASYNC_MEMCPY=y CONFIG_ASYNC_XOR=y CONFIG_ASYNC_PQ=y CONFIG_ASYNC_RAID6_RECOV=y CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_PCOMP=y CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_USER=y CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y CONFIG_CRYPTO_GF128MUL=y CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_PCRYPT=y CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=y CONFIG_CRYPTO_MCRYPTD=y CONFIG_CRYPTO_AUTHENC=y CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_ABLK_HELPER=y CONFIG_CRYPTO_GLUE_HELPER_X86=y # # Authenticated Encryption with Associated Data # CONFIG_CRYPTO_CCM=y CONFIG_CRYPTO_GCM=y CONFIG_CRYPTO_SEQIV=y # # Block modes # CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_CTR=y CONFIG_CRYPTO_CTS=y CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_LRW=y CONFIG_CRYPTO_PCBC=y CONFIG_CRYPTO_XTS=y # # Hash modes # CONFIG_CRYPTO_CMAC=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=y CONFIG_CRYPTO_VMAC=y # # Digest # CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRC32C_INTEL=y CONFIG_CRYPTO_CRC32=y CONFIG_CRYPTO_CRC32_PCLMUL=y CONFIG_CRYPTO_CRCT10DIF=y CONFIG_CRYPTO_CRCT10DIF_PCLMUL=y CONFIG_CRYPTO_GHASH=y CONFIG_CRYPTO_MD4=y CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=y CONFIG_CRYPTO_RMD128=y CONFIG_CRYPTO_RMD160=y CONFIG_CRYPTO_RMD256=y CONFIG_CRYPTO_RMD320=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA1_SSSE3=y CONFIG_CRYPTO_SHA256_SSSE3=y CONFIG_CRYPTO_SHA512_SSSE3=y CONFIG_CRYPTO_SHA1_MB=y CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=y CONFIG_CRYPTO_TGR192=y CONFIG_CRYPTO_WP512=y CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=y # # Ciphers # CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_X86_64=y CONFIG_CRYPTO_AES_NI_INTEL=y CONFIG_CRYPTO_ANUBIS=y CONFIG_CRYPTO_ARC4=y CONFIG_CRYPTO_BLOWFISH=y CONFIG_CRYPTO_BLOWFISH_COMMON=y CONFIG_CRYPTO_BLOWFISH_X86_64=y CONFIG_CRYPTO_CAMELLIA=y CONFIG_CRYPTO_CAMELLIA_X86_64=y CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=y CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=y CONFIG_CRYPTO_CAST_COMMON=y CONFIG_CRYPTO_CAST5=y CONFIG_CRYPTO_CAST5_AVX_X86_64=y CONFIG_CRYPTO_CAST6=y CONFIG_CRYPTO_CAST6_AVX_X86_64=y CONFIG_CRYPTO_DES=y CONFIG_CRYPTO_DES3_EDE_X86_64=y CONFIG_CRYPTO_FCRYPT=y CONFIG_CRYPTO_KHAZAD=y CONFIG_CRYPTO_SALSA20=y CONFIG_CRYPTO_SALSA20_X86_64=y CONFIG_CRYPTO_SEED=y CONFIG_CRYPTO_SERPENT=y CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y CONFIG_CRYPTO_SERPENT_AVX_X86_64=y CONFIG_CRYPTO_SERPENT_AVX2_X86_64=y CONFIG_CRYPTO_TEA=y CONFIG_CRYPTO_TWOFISH=y CONFIG_CRYPTO_TWOFISH_COMMON=y CONFIG_CRYPTO_TWOFISH_X86_64=y CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=y CONFIG_CRYPTO_TWOFISH_AVX_X86_64=y # # Compression # CONFIG_CRYPTO_DEFLATE=y CONFIG_CRYPTO_ZLIB=y CONFIG_CRYPTO_LZO=y CONFIG_CRYPTO_LZ4=y CONFIG_CRYPTO_LZ4HC=y # # Random Number Generation # CONFIG_CRYPTO_ANSI_CPRNG=y CONFIG_CRYPTO_DRBG_MENU=y CONFIG_CRYPTO_DRBG_HMAC=y CONFIG_CRYPTO_DRBG_HASH=y CONFIG_CRYPTO_DRBG_CTR=y CONFIG_CRYPTO_DRBG=y CONFIG_CRYPTO_USER_API=y CONFIG_CRYPTO_USER_API_HASH=y CONFIG_CRYPTO_USER_API_SKCIPHER=y CONFIG_CRYPTO_HASH_INFO=y CONFIG_CRYPTO_HW=y CONFIG_CRYPTO_DEV_PADLOCK=y CONFIG_CRYPTO_DEV_PADLOCK_AES=y CONFIG_CRYPTO_DEV_PADLOCK_SHA=y CONFIG_CRYPTO_DEV_CCP=y CONFIG_CRYPTO_DEV_CCP_DD=y CONFIG_CRYPTO_DEV_CCP_CRYPTO=y CONFIG_CRYPTO_DEV_QAT=y CONFIG_CRYPTO_DEV_QAT_DH895xCC=y CONFIG_ASYMMETRIC_KEY_TYPE=y CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y CONFIG_PUBLIC_KEY_ALGO_RSA=y CONFIG_X509_CERTIFICATE_PARSER=y CONFIG_PKCS7_MESSAGE_PARSER=y CONFIG_PKCS7_TEST_KEY=y CONFIG_SIGNED_PE_FILE_VERIFICATION=y CONFIG_HAVE_KVM=y CONFIG_HAVE_KVM_IRQCHIP=y CONFIG_HAVE_KVM_IRQFD=y CONFIG_HAVE_KVM_IRQ_ROUTING=y CONFIG_HAVE_KVM_EVENTFD=y CONFIG_KVM_APIC_ARCHITECTURE=y CONFIG_KVM_MMIO=y CONFIG_KVM_ASYNC_PF=y CONFIG_HAVE_KVM_MSI=y CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y CONFIG_KVM_VFIO=y CONFIG_VIRTUALIZATION=y CONFIG_KVM=y CONFIG_KVM_INTEL=y CONFIG_KVM_AMD=y CONFIG_KVM_MMU_AUDIT=y CONFIG_KVM_DEVICE_ASSIGNMENT=y CONFIG_BINARY_PRINTF=y # # Library routines # CONFIG_RAID6_PQ=y CONFIG_BITREVERSE=y CONFIG_RATIONAL=y CONFIG_GENERIC_STRNCPY_FROM_USER=y CONFIG_GENERIC_STRNLEN_USER=y CONFIG_GENERIC_NET_UTILS=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_GENERIC_PCI_IOMAP=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_IO=y CONFIG_PERCPU_RWSEM=y CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y CONFIG_CRC_CCITT=y CONFIG_CRC16=y CONFIG_CRC_T10DIF=y CONFIG_CRC_ITU_T=y CONFIG_CRC32=y CONFIG_CRC32_SELFTEST=y CONFIG_CRC32_SLICEBY8=y # CONFIG_CRC32_SLICEBY4 is not set # CONFIG_CRC32_SARWATE is not set # CONFIG_CRC32_BIT is not set CONFIG_CRC7=y CONFIG_LIBCRC32C=y CONFIG_CRC8=y CONFIG_CRC64_ECMA=y # CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set CONFIG_RANDOM32_SELFTEST=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_LZ4_COMPRESS=y CONFIG_LZ4HC_COMPRESS=y CONFIG_LZ4_DECOMPRESS=y CONFIG_XZ_DEC=y CONFIG_XZ_DEC_X86=y CONFIG_XZ_DEC_POWERPC=y CONFIG_XZ_DEC_IA64=y CONFIG_XZ_DEC_ARM=y CONFIG_XZ_DEC_ARMTHUMB=y CONFIG_XZ_DEC_SPARC=y CONFIG_XZ_DEC_BCJ=y CONFIG_XZ_DEC_TEST=y CONFIG_GENERIC_ALLOCATOR=y CONFIG_REED_SOLOMON=y CONFIG_REED_SOLOMON_ENC8=y CONFIG_REED_SOLOMON_DEC8=y CONFIG_REED_SOLOMON_DEC16=y CONFIG_BCH=y CONFIG_BCH_CONST_PARAMS=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=y CONFIG_TEXTSEARCH_BM=y CONFIG_TEXTSEARCH_FSM=y CONFIG_BTREE=y CONFIG_INTERVAL_TREE=y CONFIG_ASSOCIATIVE_ARRAY=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT_MAP=y CONFIG_HAS_DMA=y CONFIG_CHECK_SIGNATURE=y CONFIG_CPUMASK_OFFSTACK=y CONFIG_CPU_RMAP=y CONFIG_DQL=y CONFIG_GLOB=y CONFIG_GLOB_SELFTEST=y CONFIG_NLATTR=y CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y CONFIG_LRU_CACHE=y CONFIG_AVERAGE=y CONFIG_CLZ_TAB=y CONFIG_CORDIC=y CONFIG_DDR=y CONFIG_MPILIB=y CONFIG_SIGNATURE=y CONFIG_OID_REGISTRY=y CONFIG_UCS2_STRING=y CONFIG_FONT_SUPPORT=y CONFIG_FONTS=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_FONT_6x11=y CONFIG_FONT_7x14=y CONFIG_FONT_PEARL_8x8=y CONFIG_FONT_ACORN_8x8=y CONFIG_FONT_MINI_4x6=y CONFIG_FONT_SUN8x16=y CONFIG_FONT_SUN12x22=y CONFIG_FONT_10x18=y CONFIG_ARCH_HAS_SG_CHAIN=y ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-08 17:18 ` Mel Gorman @ 2014-09-08 17:56 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-08 17:56 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/08/2014 01:18 PM, Mel Gorman wrote: > A worse possibility is that somehow the lock is getting corrupted but > that's also a tough sell considering that the locks should be allocated > from a dedicated cache. I guess I could try breaking that to allocate > one page per lock so DEBUG_PAGEALLOC triggers but I'm not very > optimistic. I did see ptl corruption couple days ago: https://lkml.org/lkml/2014/9/4/599 Could this be related? Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-08 17:56 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-08 17:56 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/08/2014 01:18 PM, Mel Gorman wrote: > A worse possibility is that somehow the lock is getting corrupted but > that's also a tough sell considering that the locks should be allocated > from a dedicated cache. I guess I could try breaking that to allocate > one page per lock so DEBUG_PAGEALLOC triggers but I'm not very > optimistic. I did see ptl corruption couple days ago: https://lkml.org/lkml/2014/9/4/599 Could this be related? 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-08 17:56 ` Sasha Levin @ 2014-09-09 21:33 ` Mel Gorman -1 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-09-09 21:33 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Mon, Sep 08, 2014 at 01:56:55PM -0400, Sasha Levin wrote: > On 09/08/2014 01:18 PM, Mel Gorman wrote: > > A worse possibility is that somehow the lock is getting corrupted but > > that's also a tough sell considering that the locks should be allocated > > from a dedicated cache. I guess I could try breaking that to allocate > > one page per lock so DEBUG_PAGEALLOC triggers but I'm not very > > optimistic. > > I did see ptl corruption couple days ago: > > https://lkml.org/lkml/2014/9/4/599 > > Could this be related? > Possibly although the likely explanation then would be that there is just general corruption coming from somewhere. Even using your config and applying a patch to make linux-next boot (already in Tejun's tree) I was unable to reproduce the problem after running for several hours. I had to run trinity on tmpfs as ext4 and xfs blew up almost immediately so I have a few questions. 1. What filesystem are you using? 2. What compiler in case it's an experimental compiler? I ask because I think I saw a patch from you adding support so that the kernel would build with gcc 5 3. Does your hardware support TSX or anything similarly funky that would potentially affect locking? 4. How many sockets are on your test machine in case reproducing it depends in a machine large enough to open a timing race? As I'm drawing a blank on what would trigger the bug I'm hoping I can reproduce this locally and experiement a bit. Thanks. -- Mel Gorman SUSE Labs ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-09 21:33 ` Mel Gorman 0 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-09-09 21:33 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Mon, Sep 08, 2014 at 01:56:55PM -0400, Sasha Levin wrote: > On 09/08/2014 01:18 PM, Mel Gorman wrote: > > A worse possibility is that somehow the lock is getting corrupted but > > that's also a tough sell considering that the locks should be allocated > > from a dedicated cache. I guess I could try breaking that to allocate > > one page per lock so DEBUG_PAGEALLOC triggers but I'm not very > > optimistic. > > I did see ptl corruption couple days ago: > > https://lkml.org/lkml/2014/9/4/599 > > Could this be related? > Possibly although the likely explanation then would be that there is just general corruption coming from somewhere. Even using your config and applying a patch to make linux-next boot (already in Tejun's tree) I was unable to reproduce the problem after running for several hours. I had to run trinity on tmpfs as ext4 and xfs blew up almost immediately so I have a few questions. 1. What filesystem are you using? 2. What compiler in case it's an experimental compiler? I ask because I think I saw a patch from you adding support so that the kernel would build with gcc 5 3. Does your hardware support TSX or anything similarly funky that would potentially affect locking? 4. How many sockets are on your test machine in case reproducing it depends in a machine large enough to open a timing race? As I'm drawing a blank on what would trigger the bug I'm hoping I can reproduce this locally and experiement a bit. Thanks. -- Mel Gorman SUSE Labs -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-09 21:33 ` Mel Gorman @ 2014-09-09 22:20 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-09 22:20 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/09/2014 05:33 PM, Mel Gorman wrote: > On Mon, Sep 08, 2014 at 01:56:55PM -0400, Sasha Levin wrote: >> On 09/08/2014 01:18 PM, Mel Gorman wrote: >>> A worse possibility is that somehow the lock is getting corrupted but >>> that's also a tough sell considering that the locks should be allocated >>> from a dedicated cache. I guess I could try breaking that to allocate >>> one page per lock so DEBUG_PAGEALLOC triggers but I'm not very >>> optimistic. >> >> I did see ptl corruption couple days ago: >> >> https://lkml.org/lkml/2014/9/4/599 >> >> Could this be related? >> > > Possibly although the likely explanation then would be that there is > just general corruption coming from somewhere. Even using your config > and applying a patch to make linux-next boot (already in Tejun's tree) > I was unable to reproduce the problem after running for several hours. I > had to run trinity on tmpfs as ext4 and xfs blew up almost immediately > so I have a few questions. I agree it could be a case of random corruption somewhere else, it's just that the amount of times this exact issue reproduced > 1. What filesystem are you using? virtio-9p. I'm willing to try something more "common" if you feel this could be related, but I haven't seen any issues coming out of 9p in a while now. > 2. What compiler in case it's an experimental compiler? I ask because I > think I saw a patch from you adding support so that the kernel would > build with gcc 5 Right, I've been testing with gcc 5 as well as Debian's gcc 4.7.2, it reproduces with both compilers. > 3. Does your hardware support TSX or anything similarly funky that would > potentially affect locking? Not that I know of, here are the cpu flags for reference: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 x2apic popcnt lahf_lm ida epb dtherm tpr_shadow vnmi flexpriority ept vpid > 4. How many sockets are on your test machine in case reproducing it > depends in a machine large enough to open a timing race? 128 sockets. > As I'm drawing a blank on what would trigger the bug I'm hoping I can > reproduce this locally and experiement a bit. I was thinking about sneaking in something like the following (untested) patch to see if it's really memory corruption that is wiping out stuff: diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h index 0f9724c..0205655 100644 --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -25,6 +25,7 @@ #define _PAGE_BIT_SPLITTING _PAGE_BIT_SOFTW2 /* only valid on a PSE pmd */ #define _PAGE_BIT_IOMAP _PAGE_BIT_SOFTW2 /* flag used to indicate IO mapping */ #define _PAGE_BIT_HIDDEN _PAGE_BIT_SOFTW3 /* hidden by kmemcheck */ +#define _PAGE_BIT_SANITY _PAGE_BIT_SOFTW3 /* Memory corruption canary */ #define _PAGE_BIT_SOFT_DIRTY _PAGE_BIT_SOFTW3 /* software dirty tracking */ #define _PAGE_BIT_NX 63 /* No execute: only valid after cpuid check */ @@ -66,6 +67,8 @@ #define _PAGE_HIDDEN (_AT(pteval_t, 0)) #endif +#define _PAGE_SANITY (_AT(pteval_t, 1) << _PAGE_BIT_SANITY) + /* * The same hidden bit is used by kmemcheck, but since kmemcheck * works on kernel pages while soft-dirty engine on user space, @@ -312,7 +315,7 @@ static inline pmdval_t pmd_flags(pmd_t pmd) static inline pte_t native_make_pte(pteval_t val) { - return (pte_t) { .pte = val }; + return (pte_t) { .pte = val | _PAGE_SANITY }; } static inline pteval_t native_pte_val(pte_t pte) diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h index ffea570..bc897a1 100644 --- a/include/asm-generic/pgtable.h +++ b/include/asm-generic/pgtable.h @@ -720,6 +720,8 @@ static inline pmd_t pmd_mknonnuma(pmd_t pmd) static inline pte_t pte_mknuma(pte_t pte) { pteval_t val = pte_val(pte); + + VM_BUG_ON(!(val & _PAGE_SANITY)); VM_BUG_ON(!(val & _PAGE_PRESENT)); Does it make sense at all? Thanks, Sasha ^ permalink raw reply related [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-09 22:20 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-09 22:20 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/09/2014 05:33 PM, Mel Gorman wrote: > On Mon, Sep 08, 2014 at 01:56:55PM -0400, Sasha Levin wrote: >> On 09/08/2014 01:18 PM, Mel Gorman wrote: >>> A worse possibility is that somehow the lock is getting corrupted but >>> that's also a tough sell considering that the locks should be allocated >>> from a dedicated cache. I guess I could try breaking that to allocate >>> one page per lock so DEBUG_PAGEALLOC triggers but I'm not very >>> optimistic. >> >> I did see ptl corruption couple days ago: >> >> https://lkml.org/lkml/2014/9/4/599 >> >> Could this be related? >> > > Possibly although the likely explanation then would be that there is > just general corruption coming from somewhere. Even using your config > and applying a patch to make linux-next boot (already in Tejun's tree) > I was unable to reproduce the problem after running for several hours. I > had to run trinity on tmpfs as ext4 and xfs blew up almost immediately > so I have a few questions. I agree it could be a case of random corruption somewhere else, it's just that the amount of times this exact issue reproduced > 1. What filesystem are you using? virtio-9p. I'm willing to try something more "common" if you feel this could be related, but I haven't seen any issues coming out of 9p in a while now. > 2. What compiler in case it's an experimental compiler? I ask because I > think I saw a patch from you adding support so that the kernel would > build with gcc 5 Right, I've been testing with gcc 5 as well as Debian's gcc 4.7.2, it reproduces with both compilers. > 3. Does your hardware support TSX or anything similarly funky that would > potentially affect locking? Not that I know of, here are the cpu flags for reference: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 x2apic popcnt lahf_lm ida epb dtherm tpr_shadow vnmi flexpriority ept vpid > 4. How many sockets are on your test machine in case reproducing it > depends in a machine large enough to open a timing race? 128 sockets. > As I'm drawing a blank on what would trigger the bug I'm hoping I can > reproduce this locally and experiement a bit. I was thinking about sneaking in something like the following (untested) patch to see if it's really memory corruption that is wiping out stuff: diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h index 0f9724c..0205655 100644 --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -25,6 +25,7 @@ #define _PAGE_BIT_SPLITTING _PAGE_BIT_SOFTW2 /* only valid on a PSE pmd */ #define _PAGE_BIT_IOMAP _PAGE_BIT_SOFTW2 /* flag used to indicate IO mapping */ #define _PAGE_BIT_HIDDEN _PAGE_BIT_SOFTW3 /* hidden by kmemcheck */ +#define _PAGE_BIT_SANITY _PAGE_BIT_SOFTW3 /* Memory corruption canary */ #define _PAGE_BIT_SOFT_DIRTY _PAGE_BIT_SOFTW3 /* software dirty tracking */ #define _PAGE_BIT_NX 63 /* No execute: only valid after cpuid check */ @@ -66,6 +67,8 @@ #define _PAGE_HIDDEN (_AT(pteval_t, 0)) #endif +#define _PAGE_SANITY (_AT(pteval_t, 1) << _PAGE_BIT_SANITY) + /* * The same hidden bit is used by kmemcheck, but since kmemcheck * works on kernel pages while soft-dirty engine on user space, @@ -312,7 +315,7 @@ static inline pmdval_t pmd_flags(pmd_t pmd) static inline pte_t native_make_pte(pteval_t val) { - return (pte_t) { .pte = val }; + return (pte_t) { .pte = val | _PAGE_SANITY }; } static inline pteval_t native_pte_val(pte_t pte) diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h index ffea570..bc897a1 100644 --- a/include/asm-generic/pgtable.h +++ b/include/asm-generic/pgtable.h @@ -720,6 +720,8 @@ static inline pmd_t pmd_mknonnuma(pmd_t pmd) static inline pte_t pte_mknuma(pte_t pte) { pteval_t val = pte_val(pte); + + VM_BUG_ON(!(val & _PAGE_SANITY)); VM_BUG_ON(!(val & _PAGE_PRESENT)); Does it make sense at all? 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 related [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-09 22:20 ` Sasha Levin @ 2014-09-10 2:45 ` Hugh Dickins -1 siblings, 0 replies; 86+ messages in thread From: Hugh Dickins @ 2014-09-10 2:45 UTC (permalink / raw) To: Sasha Levin Cc: Mel Gorman, Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Tue, 9 Sep 2014, Sasha Levin wrote: > On 09/09/2014 05:33 PM, Mel Gorman wrote: > > On Mon, Sep 08, 2014 at 01:56:55PM -0400, Sasha Levin wrote: > >> On 09/08/2014 01:18 PM, Mel Gorman wrote: > >>> A worse possibility is that somehow the lock is getting corrupted but > >>> that's also a tough sell considering that the locks should be allocated > >>> from a dedicated cache. I guess I could try breaking that to allocate > >>> one page per lock so DEBUG_PAGEALLOC triggers but I'm not very > >>> optimistic. > >> > >> I did see ptl corruption couple days ago: > >> > >> https://lkml.org/lkml/2014/9/4/599 > >> > >> Could this be related? > >> > > > > Possibly although the likely explanation then would be that there is > > just general corruption coming from somewhere. Even using your config > > and applying a patch to make linux-next boot (already in Tejun's tree) > > I was unable to reproduce the problem after running for several hours. I > > had to run trinity on tmpfs as ext4 and xfs blew up almost immediately > > so I have a few questions. > > I agree it could be a case of random corruption somewhere else, it's just > that the amount of times this exact issue reproduced Yes, I doubt it's random corruption; but I've been no more successful than Mel in working it out (I share responsibility for that VM_BUG_ON). Sasha, you say you're getting plenty of these now, but I've only seen the dump for one of them, on Aug26: please post a few more dumps, so that we can look for commonality. And please attach a disassembly of change_protection_range() (noting which of the dumps it corresponds to, in case it has changed around): "Code" just shows a cluster of ud2s for the unlikely bugs at end of the function, we cannot tell at all what should be in the registers by then. I've been rather assuming that the 9d340902 seen in many of the registers in that Aug26 dump is the pte val in question: that's SOFT_DIRTY|PROTNONE|RW. I think RW on PROTNONE is unusual but not impossible (migration entry replacement racing with mprotect setting PROT_NONE, after it's updated vm_page_prot, before it's reached the page table). But exciting though that line of thought is, I cannot actually bring it to a pte_mknuma bug, or any bug at all. Mel, no way can it be the cause of this bug - unless Sasha's later traces actually show a different stack - but I don't see the call to change_prot_numa() from queue_pages_range() sharing the same avoidance of PROT_NONE that task_numa_work() has (though it does have an outdated comment about PROT_NONE which should be removed). So I think that site probably does need PROT_NONE checking added. Hugh ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-10 2:45 ` Hugh Dickins 0 siblings, 0 replies; 86+ messages in thread From: Hugh Dickins @ 2014-09-10 2:45 UTC (permalink / raw) To: Sasha Levin Cc: Mel Gorman, Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Tue, 9 Sep 2014, Sasha Levin wrote: > On 09/09/2014 05:33 PM, Mel Gorman wrote: > > On Mon, Sep 08, 2014 at 01:56:55PM -0400, Sasha Levin wrote: > >> On 09/08/2014 01:18 PM, Mel Gorman wrote: > >>> A worse possibility is that somehow the lock is getting corrupted but > >>> that's also a tough sell considering that the locks should be allocated > >>> from a dedicated cache. I guess I could try breaking that to allocate > >>> one page per lock so DEBUG_PAGEALLOC triggers but I'm not very > >>> optimistic. > >> > >> I did see ptl corruption couple days ago: > >> > >> https://lkml.org/lkml/2014/9/4/599 > >> > >> Could this be related? > >> > > > > Possibly although the likely explanation then would be that there is > > just general corruption coming from somewhere. Even using your config > > and applying a patch to make linux-next boot (already in Tejun's tree) > > I was unable to reproduce the problem after running for several hours. I > > had to run trinity on tmpfs as ext4 and xfs blew up almost immediately > > so I have a few questions. > > I agree it could be a case of random corruption somewhere else, it's just > that the amount of times this exact issue reproduced Yes, I doubt it's random corruption; but I've been no more successful than Mel in working it out (I share responsibility for that VM_BUG_ON). Sasha, you say you're getting plenty of these now, but I've only seen the dump for one of them, on Aug26: please post a few more dumps, so that we can look for commonality. And please attach a disassembly of change_protection_range() (noting which of the dumps it corresponds to, in case it has changed around): "Code" just shows a cluster of ud2s for the unlikely bugs at end of the function, we cannot tell at all what should be in the registers by then. I've been rather assuming that the 9d340902 seen in many of the registers in that Aug26 dump is the pte val in question: that's SOFT_DIRTY|PROTNONE|RW. I think RW on PROTNONE is unusual but not impossible (migration entry replacement racing with mprotect setting PROT_NONE, after it's updated vm_page_prot, before it's reached the page table). But exciting though that line of thought is, I cannot actually bring it to a pte_mknuma bug, or any bug at all. Mel, no way can it be the cause of this bug - unless Sasha's later traces actually show a different stack - but I don't see the call to change_prot_numa() from queue_pages_range() sharing the same avoidance of PROT_NONE that task_numa_work() has (though it does have an outdated comment about PROT_NONE which should be removed). So I think that site probably does need PROT_NONE checking added. Hugh -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-10 2:45 ` Hugh Dickins @ 2014-09-10 12:47 ` Mel Gorman -1 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-09-10 12:47 UTC (permalink / raw) To: Hugh Dickins Cc: Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Tue, Sep 09, 2014 at 07:45:26PM -0700, Hugh Dickins wrote: > On Tue, 9 Sep 2014, Sasha Levin wrote: > > On 09/09/2014 05:33 PM, Mel Gorman wrote: > > > On Mon, Sep 08, 2014 at 01:56:55PM -0400, Sasha Levin wrote: > > >> On 09/08/2014 01:18 PM, Mel Gorman wrote: > > >>> A worse possibility is that somehow the lock is getting corrupted but > > >>> that's also a tough sell considering that the locks should be allocated > > >>> from a dedicated cache. I guess I could try breaking that to allocate > > >>> one page per lock so DEBUG_PAGEALLOC triggers but I'm not very > > >>> optimistic. > > >> > > >> I did see ptl corruption couple days ago: > > >> > > >> https://lkml.org/lkml/2014/9/4/599 > > >> > > >> Could this be related? > > >> > > > > > > Possibly although the likely explanation then would be that there is > > > just general corruption coming from somewhere. Even using your config > > > and applying a patch to make linux-next boot (already in Tejun's tree) > > > I was unable to reproduce the problem after running for several hours. I > > > had to run trinity on tmpfs as ext4 and xfs blew up almost immediately > > > so I have a few questions. > > > > I agree it could be a case of random corruption somewhere else, it's just > > that the amount of times this exact issue reproduced > > Yes, I doubt it's random corruption; but I've been no more successful > than Mel in working it out (I share responsibility for that VM_BUG_ON). > > Sasha, you say you're getting plenty of these now, but I've only seen > the dump for one of them, on Aug26: please post a few more dumps, so > that we can look for commonality. > It's also worth knowing that this is a test running in KVM and fake NUMA. The hint was that the filesystem used was virtio-9p. I haven't formulated a theory on how KVM could cause any damage here but it's interesting. > And please attach a disassembly of change_protection_range() (noting > which of the dumps it corresponds to, in case it has changed around): > "Code" just shows a cluster of ud2s for the unlikely bugs at end of the > function, we cannot tell at all what should be in the registers by then. > > I've been rather assuming that the 9d340902 seen in many of the > registers in that Aug26 dump is the pte val in question: that's > SOFT_DIRTY|PROTNONE|RW. > > I think RW on PROTNONE is unusual but not impossible (migration entry > replacement racing with mprotect setting PROT_NONE, after it's updated > vm_page_prot, before it's reached the page table). At the risk of sounding thick, I need to spell this out because I'm having trouble seeing exactly what race you are thinking of. Migration entry replacement is protected against parallel NUMA hinting updates by the page table lock (either PMD or PTE level). It's taken by remove_migration_pte on one side and lock_pte_protection on the other. For the mprotect case racing again migration, migration entries are not present so change_pte_range() should ignore it. On migration completion the VMA flags determine the permissions of the new PTE. Parallel faults wait on the migration entry and see the correct value afterwards. When creating migration entries, try_to_unmap calls page_check_address which takes the PTL before doing anything. On the mprotect side, lock_pte_protection will block before seeing PROTNONE. I think the race you are thinking of is a migration entry created for write, parallel mprotect(PROTNONE) and migration completion. The migration entry was created for write but remove_migration_pte does not double check the VMA protections and mmap_sem is not taken for write across a full migration to protect against changes to vm_page_prot. However, change_pte_range checks for migration entries marked for write under the PTL and marks them read if one is encountered. The consequence is that we potentially take a spurious fault to mark the PTE write again after migration completes but I can't see how that causes a problem as such. I'm missing some part of your reasoning that leads to the RW|PROTNONE :( > But exciting though > that line of thought is, I cannot actually bring it to a pte_mknuma bug, > or any bug at all. > On x86, PROTNONE|RW translates as GLOBAL|RW which would be unexpected. It wouldn't cause this bug but it's sufficiently suspicious to be worth correcting. In case this is the race you're thinking of, the patch is below. Unfortunately, I cannot see how it would affect this problem but worth giving a whirl anyway. > Mel, no way can it be the cause of this bug - unless Sasha's later > traces actually show a different stack - but I don't see the call > to change_prot_numa() from queue_pages_range() sharing the same > avoidance of PROT_NONE that task_numa_work() has (though it does > have an outdated comment about PROT_NONE which should be removed). > So I think that site probably does need PROT_NONE checking added. > That site should have checked PROT_NONE but it can't be the same bug that trinity is seeing. Minimally trinity is unaware of MPOL_MF_LAZY according to git grep of the trinity source. Worth adding this to the debugging mix? It should warn if it encounters the problem but avoid adding the problematic RW bit. ---8<--- migrate: debug patch to try identify race between migration completion and mprotect A migration entry is marked as write if pte_write was true at the time the entry was created. The VMA protections are not double checked when migration entries are being removed but mprotect itself will mark write-migration-entries as read to avoid problems. It means we potentially take a spurious fault to mark these ptes write again but otherwise it's harmless. Still, one dump indicates that this situation can actually happen so this debugging patch spits out a warning if the situation occurs and hopefully the resulting warning will contain a clue as to how exactly it happens Not-signed-off --- mm/migrate.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/mm/migrate.c b/mm/migrate.c index 09d489c..631725c 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -146,8 +146,16 @@ static int remove_migration_pte(struct page *new, struct vm_area_struct *vma, pte = pte_mkold(mk_pte(new, vma->vm_page_prot)); if (pte_swp_soft_dirty(*ptep)) pte = pte_mksoft_dirty(pte); - if (is_write_migration_entry(entry)) - pte = pte_mkwrite(pte); + if (is_write_migration_entry(entry)) { + /* + * This WARN_ON_ONCE is temporary for the purposes of seeing if + * it's a case encountered by trinity in Sasha's testing + */ + if (!(vma->vm_flags & (VM_WRITE))) + WARN_ON_ONCE(1); + else + pte = pte_mkwrite(pte); + } #ifdef CONFIG_HUGETLB_PAGE if (PageHuge(new)) { pte = pte_mkhuge(pte); ^ permalink raw reply related [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-10 12:47 ` Mel Gorman 0 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-09-10 12:47 UTC (permalink / raw) To: Hugh Dickins Cc: Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Tue, Sep 09, 2014 at 07:45:26PM -0700, Hugh Dickins wrote: > On Tue, 9 Sep 2014, Sasha Levin wrote: > > On 09/09/2014 05:33 PM, Mel Gorman wrote: > > > On Mon, Sep 08, 2014 at 01:56:55PM -0400, Sasha Levin wrote: > > >> On 09/08/2014 01:18 PM, Mel Gorman wrote: > > >>> A worse possibility is that somehow the lock is getting corrupted but > > >>> that's also a tough sell considering that the locks should be allocated > > >>> from a dedicated cache. I guess I could try breaking that to allocate > > >>> one page per lock so DEBUG_PAGEALLOC triggers but I'm not very > > >>> optimistic. > > >> > > >> I did see ptl corruption couple days ago: > > >> > > >> https://lkml.org/lkml/2014/9/4/599 > > >> > > >> Could this be related? > > >> > > > > > > Possibly although the likely explanation then would be that there is > > > just general corruption coming from somewhere. Even using your config > > > and applying a patch to make linux-next boot (already in Tejun's tree) > > > I was unable to reproduce the problem after running for several hours. I > > > had to run trinity on tmpfs as ext4 and xfs blew up almost immediately > > > so I have a few questions. > > > > I agree it could be a case of random corruption somewhere else, it's just > > that the amount of times this exact issue reproduced > > Yes, I doubt it's random corruption; but I've been no more successful > than Mel in working it out (I share responsibility for that VM_BUG_ON). > > Sasha, you say you're getting plenty of these now, but I've only seen > the dump for one of them, on Aug26: please post a few more dumps, so > that we can look for commonality. > It's also worth knowing that this is a test running in KVM and fake NUMA. The hint was that the filesystem used was virtio-9p. I haven't formulated a theory on how KVM could cause any damage here but it's interesting. > And please attach a disassembly of change_protection_range() (noting > which of the dumps it corresponds to, in case it has changed around): > "Code" just shows a cluster of ud2s for the unlikely bugs at end of the > function, we cannot tell at all what should be in the registers by then. > > I've been rather assuming that the 9d340902 seen in many of the > registers in that Aug26 dump is the pte val in question: that's > SOFT_DIRTY|PROTNONE|RW. > > I think RW on PROTNONE is unusual but not impossible (migration entry > replacement racing with mprotect setting PROT_NONE, after it's updated > vm_page_prot, before it's reached the page table). At the risk of sounding thick, I need to spell this out because I'm having trouble seeing exactly what race you are thinking of. Migration entry replacement is protected against parallel NUMA hinting updates by the page table lock (either PMD or PTE level). It's taken by remove_migration_pte on one side and lock_pte_protection on the other. For the mprotect case racing again migration, migration entries are not present so change_pte_range() should ignore it. On migration completion the VMA flags determine the permissions of the new PTE. Parallel faults wait on the migration entry and see the correct value afterwards. When creating migration entries, try_to_unmap calls page_check_address which takes the PTL before doing anything. On the mprotect side, lock_pte_protection will block before seeing PROTNONE. I think the race you are thinking of is a migration entry created for write, parallel mprotect(PROTNONE) and migration completion. The migration entry was created for write but remove_migration_pte does not double check the VMA protections and mmap_sem is not taken for write across a full migration to protect against changes to vm_page_prot. However, change_pte_range checks for migration entries marked for write under the PTL and marks them read if one is encountered. The consequence is that we potentially take a spurious fault to mark the PTE write again after migration completes but I can't see how that causes a problem as such. I'm missing some part of your reasoning that leads to the RW|PROTNONE :( > But exciting though > that line of thought is, I cannot actually bring it to a pte_mknuma bug, > or any bug at all. > On x86, PROTNONE|RW translates as GLOBAL|RW which would be unexpected. It wouldn't cause this bug but it's sufficiently suspicious to be worth correcting. In case this is the race you're thinking of, the patch is below. Unfortunately, I cannot see how it would affect this problem but worth giving a whirl anyway. > Mel, no way can it be the cause of this bug - unless Sasha's later > traces actually show a different stack - but I don't see the call > to change_prot_numa() from queue_pages_range() sharing the same > avoidance of PROT_NONE that task_numa_work() has (though it does > have an outdated comment about PROT_NONE which should be removed). > So I think that site probably does need PROT_NONE checking added. > That site should have checked PROT_NONE but it can't be the same bug that trinity is seeing. Minimally trinity is unaware of MPOL_MF_LAZY according to git grep of the trinity source. Worth adding this to the debugging mix? It should warn if it encounters the problem but avoid adding the problematic RW bit. ---8<--- migrate: debug patch to try identify race between migration completion and mprotect A migration entry is marked as write if pte_write was true at the time the entry was created. The VMA protections are not double checked when migration entries are being removed but mprotect itself will mark write-migration-entries as read to avoid problems. It means we potentially take a spurious fault to mark these ptes write again but otherwise it's harmless. Still, one dump indicates that this situation can actually happen so this debugging patch spits out a warning if the situation occurs and hopefully the resulting warning will contain a clue as to how exactly it happens Not-signed-off --- mm/migrate.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/mm/migrate.c b/mm/migrate.c index 09d489c..631725c 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -146,8 +146,16 @@ static int remove_migration_pte(struct page *new, struct vm_area_struct *vma, pte = pte_mkold(mk_pte(new, vma->vm_page_prot)); if (pte_swp_soft_dirty(*ptep)) pte = pte_mksoft_dirty(pte); - if (is_write_migration_entry(entry)) - pte = pte_mkwrite(pte); + if (is_write_migration_entry(entry)) { + /* + * This WARN_ON_ONCE is temporary for the purposes of seeing if + * it's a case encountered by trinity in Sasha's testing + */ + if (!(vma->vm_flags & (VM_WRITE))) + WARN_ON_ONCE(1); + else + pte = pte_mkwrite(pte); + } #ifdef CONFIG_HUGETLB_PAGE if (PageHuge(new)) { pte = pte_mkhuge(pte); -- 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] 86+ messages in thread
* Trinity and mbind flags (WAS: Re: mm: BUG in unmap_page_range) 2014-09-10 12:47 ` Mel Gorman @ 2014-09-10 14:24 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-10 14:24 UTC (permalink / raw) To: Dave Jones Cc: Mel Gorman, Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/10/2014 08:47 AM, Mel Gorman wrote: > That site should have checked PROT_NONE but it can't be the same bug > that trinity is seeing. Minimally trinity is unaware of MPOL_MF_LAZY > according to git grep of the trinity source. Actually, if I'm reading it correctly I think that Trinity handles mbind() calls wrong. It passes the wrong values for mode flags and actual flags. Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Trinity and mbind flags (WAS: Re: mm: BUG in unmap_page_range) @ 2014-09-10 14:24 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-10 14:24 UTC (permalink / raw) To: Dave Jones Cc: Mel Gorman, Hugh Dickins, linux-mm, Andrew Morton, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/10/2014 08:47 AM, Mel Gorman wrote: > That site should have checked PROT_NONE but it can't be the same bug > that trinity is seeing. Minimally trinity is unaware of MPOL_MF_LAZY > according to git grep of the trinity source. Actually, if I'm reading it correctly I think that Trinity handles mbind() calls wrong. It passes the wrong values for mode flags and actual flags. 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] 86+ messages in thread
* Re: Trinity and mbind flags (WAS: Re: mm: BUG in unmap_page_range) 2014-09-10 14:24 ` Sasha Levin @ 2014-09-10 14:33 ` Dave Jones -1 siblings, 0 replies; 86+ messages in thread From: Dave Jones @ 2014-09-10 14:33 UTC (permalink / raw) To: Sasha Levin Cc: Mel Gorman, Hugh Dickins, linux-mm, Andrew Morton, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Wed, Sep 10, 2014 at 10:24:40AM -0400, Sasha Levin wrote: > On 09/10/2014 08:47 AM, Mel Gorman wrote: > > That site should have checked PROT_NONE but it can't be the same bug > > that trinity is seeing. Minimally trinity is unaware of MPOL_MF_LAZY > > according to git grep of the trinity source. > > Actually, if I'm reading it correctly I think that Trinity handles mbind() > calls wrong. It passes the wrong values for mode flags and actual flags. Ugh, I think you're right. I misinterpreted the man page that mentions that flags like MPOL_F_STATIC_NODES/RELATIVE_NODES are OR'd with the mode, and instead dumped those flags into .. the flags field. So the 'flags' argument it generates is crap, because I didn't add any of the actual correct values. I'll fix it up, though if it's currently finding bugs, you might want to keep the current syscalls/mbind.c for now. Dave ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Trinity and mbind flags (WAS: Re: mm: BUG in unmap_page_range) @ 2014-09-10 14:33 ` Dave Jones 0 siblings, 0 replies; 86+ messages in thread From: Dave Jones @ 2014-09-10 14:33 UTC (permalink / raw) To: Sasha Levin Cc: Mel Gorman, Hugh Dickins, linux-mm, Andrew Morton, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Wed, Sep 10, 2014 at 10:24:40AM -0400, Sasha Levin wrote: > On 09/10/2014 08:47 AM, Mel Gorman wrote: > > That site should have checked PROT_NONE but it can't be the same bug > > that trinity is seeing. Minimally trinity is unaware of MPOL_MF_LAZY > > according to git grep of the trinity source. > > Actually, if I'm reading it correctly I think that Trinity handles mbind() > calls wrong. It passes the wrong values for mode flags and actual flags. Ugh, I think you're right. I misinterpreted the man page that mentions that flags like MPOL_F_STATIC_NODES/RELATIVE_NODES are OR'd with the mode, and instead dumped those flags into .. the flags field. So the 'flags' argument it generates is crap, because I didn't add any of the actual correct values. I'll fix it up, though if it's currently finding bugs, you might want to keep the current syscalls/mbind.c for now. Dave -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-10 12:47 ` Mel Gorman @ 2014-09-10 19:06 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-10 19:06 UTC (permalink / raw) To: Mel Gorman, Hugh Dickins Cc: linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/10/2014 08:47 AM, Mel Gorman wrote: > migrate: debug patch to try identify race between migration completion and mprotect > > A migration entry is marked as write if pte_write was true at the > time the entry was created. The VMA protections are not double checked > when migration entries are being removed but mprotect itself will mark > write-migration-entries as read to avoid problems. It means we potentially > take a spurious fault to mark these ptes write again but otherwise it's > harmless. Still, one dump indicates that this situation can actually > happen so this debugging patch spits out a warning if the situation occurs > and hopefully the resulting warning will contain a clue as to how exactly > it happens > > Not-signed-off > --- > mm/migrate.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/mm/migrate.c b/mm/migrate.c > index 09d489c..631725c 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -146,8 +146,16 @@ static int remove_migration_pte(struct page *new, struct vm_area_struct *vma, > pte = pte_mkold(mk_pte(new, vma->vm_page_prot)); > if (pte_swp_soft_dirty(*ptep)) > pte = pte_mksoft_dirty(pte); > - if (is_write_migration_entry(entry)) > - pte = pte_mkwrite(pte); > + if (is_write_migration_entry(entry)) { > + /* > + * This WARN_ON_ONCE is temporary for the purposes of seeing if > + * it's a case encountered by trinity in Sasha's testing > + */ > + if (!(vma->vm_flags & (VM_WRITE))) > + WARN_ON_ONCE(1); > + else > + pte = pte_mkwrite(pte); > + } > #ifdef CONFIG_HUGETLB_PAGE > if (PageHuge(new)) { > pte = pte_mkhuge(pte); I seem to have hit this warning: [ 4782.617806] WARNING: CPU: 10 PID: 21180 at mm/migrate.c:155 remove_migration_pte+0x3f7/0x420() [ 4782.619315] Modules linked in: [ 4782.622189] [ 4782.622501] CPU: 10 PID: 21180 Comm: trinity-main Tainted: G W 3.17.0-rc4-next-20140910-sasha-00032-g6825fb5-dirty #1137 [ 4782.624344] 0000000000000009 ffff8800193eb770 ffffffffa04c742a 0000000000000000 [ 4782.627801] ffff8800193eb7a8 ffffffff9d16e55d 00007f2458d89000 ffff880120959600 [ 4782.629283] ffff88012b02c000 ffffea002abeab00 ffff88063118da90 ffff8800193eb7b8 [ 4782.631353] Call Trace: [ 4782.633789] [<ffffffffa04c742a>] dump_stack+0x4e/0x7a [ 4782.634314] [<ffffffff9d16e55d>] warn_slowpath_common+0x7d/0xa0 [ 4782.634877] [<ffffffff9d16e63a>] warn_slowpath_null+0x1a/0x20 [ 4782.635430] [<ffffffff9d315487>] remove_migration_pte+0x3f7/0x420 [ 4782.636042] [<ffffffff9d2e99cf>] rmap_walk+0xef/0x380 [ 4782.636544] [<ffffffff9d3147f1>] remove_migration_ptes+0x41/0x50 [ 4782.637130] [<ffffffff9d315090>] ? __migration_entry_wait.isra.24+0x160/0x160 [ 4782.639928] [<ffffffff9d3154b0>] ? remove_migration_pte+0x420/0x420 [ 4782.640616] [<ffffffff9d31671b>] move_to_new_page+0x16b/0x230 [ 4782.641251] [<ffffffff9d2e9e8c>] ? try_to_unmap+0x6c/0xf0 [ 4782.643950] [<ffffffff9d2e88a0>] ? try_to_unmap_nonlinear+0x5c0/0x5c0 [ 4782.644690] [<ffffffff9d2e70a0>] ? invalid_migration_vma+0x30/0x30 [ 4782.645273] [<ffffffff9d2e82e0>] ? page_remove_rmap+0x320/0x320 [ 4782.646072] [<ffffffff9d31717c>] migrate_pages+0x85c/0x930 [ 4782.646701] [<ffffffff9d2d0e20>] ? isolate_freepages_block+0x410/0x410 [ 4782.647407] [<ffffffff9d2cfa60>] ? arch_local_save_flags+0x30/0x30 [ 4782.648114] [<ffffffff9d2d1803>] compact_zone+0x4d3/0x8a0 [ 4782.650157] [<ffffffff9d2d1c2f>] compact_zone_order+0x5f/0xa0 [ 4782.651014] [<ffffffff9d2d1f87>] try_to_compact_pages+0x127/0x2f0 [ 4782.651656] [<ffffffff9d2b0c98>] __alloc_pages_direct_compact+0x68/0x200 [ 4782.652313] [<ffffffff9d2b17ca>] __alloc_pages_nodemask+0x99a/0xd90 [ 4782.652916] [<ffffffff9d300a1c>] alloc_pages_vma+0x13c/0x270 [ 4782.653618] [<ffffffff9d31d914>] ? do_huge_pmd_wp_page+0x494/0xc90 [ 4782.654487] [<ffffffff9d31d914>] do_huge_pmd_wp_page+0x494/0xc90 [ 4782.656045] [<ffffffff9d320d20>] ? __mem_cgroup_count_vm_event+0xd0/0x240 [ 4782.657089] [<ffffffff9d2dcb7d>] handle_mm_fault+0x8bd/0xc50 [ 4782.660931] [<ffffffff9d1d26e6>] ? __lock_is_held+0x56/0x80 [ 4782.662695] [<ffffffff9d0c7bc7>] __do_page_fault+0x1b7/0x660 [ 4782.663259] [<ffffffff9d1cdc5e>] ? put_lock_stats.isra.13+0xe/0x30 [ 4782.663851] [<ffffffff9d1abf41>] ? vtime_account_user+0x91/0xa0 [ 4782.664419] [<ffffffff9d2a2c35>] ? context_tracking_user_exit+0xb5/0x1b0 [ 4782.665119] [<ffffffff9db6e103>] ? __this_cpu_preempt_check+0x13/0x20 [ 4782.665969] [<ffffffff9d1ce2e2>] ? trace_hardirqs_off_caller+0xe2/0x1b0 [ 4782.666634] [<ffffffff9d0c8141>] trace_do_page_fault+0x51/0x2b0 [ 4782.667257] [<ffffffff9d0bee83>] do_async_page_fault+0x63/0xd0 [ 4782.667871] [<ffffffffa0511018>] async_page_fault+0x28/0x30 Although it wasn't followed by anything else, and I've seen the original issue getting triggered without this WARN showing up, so it seems like a different, unrelated issue? Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-10 19:06 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-10 19:06 UTC (permalink / raw) To: Mel Gorman, Hugh Dickins Cc: linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/10/2014 08:47 AM, Mel Gorman wrote: > migrate: debug patch to try identify race between migration completion and mprotect > > A migration entry is marked as write if pte_write was true at the > time the entry was created. The VMA protections are not double checked > when migration entries are being removed but mprotect itself will mark > write-migration-entries as read to avoid problems. It means we potentially > take a spurious fault to mark these ptes write again but otherwise it's > harmless. Still, one dump indicates that this situation can actually > happen so this debugging patch spits out a warning if the situation occurs > and hopefully the resulting warning will contain a clue as to how exactly > it happens > > Not-signed-off > --- > mm/migrate.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/mm/migrate.c b/mm/migrate.c > index 09d489c..631725c 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -146,8 +146,16 @@ static int remove_migration_pte(struct page *new, struct vm_area_struct *vma, > pte = pte_mkold(mk_pte(new, vma->vm_page_prot)); > if (pte_swp_soft_dirty(*ptep)) > pte = pte_mksoft_dirty(pte); > - if (is_write_migration_entry(entry)) > - pte = pte_mkwrite(pte); > + if (is_write_migration_entry(entry)) { > + /* > + * This WARN_ON_ONCE is temporary for the purposes of seeing if > + * it's a case encountered by trinity in Sasha's testing > + */ > + if (!(vma->vm_flags & (VM_WRITE))) > + WARN_ON_ONCE(1); > + else > + pte = pte_mkwrite(pte); > + } > #ifdef CONFIG_HUGETLB_PAGE > if (PageHuge(new)) { > pte = pte_mkhuge(pte); I seem to have hit this warning: [ 4782.617806] WARNING: CPU: 10 PID: 21180 at mm/migrate.c:155 remove_migration_pte+0x3f7/0x420() [ 4782.619315] Modules linked in: [ 4782.622189] [ 4782.622501] CPU: 10 PID: 21180 Comm: trinity-main Tainted: G W 3.17.0-rc4-next-20140910-sasha-00032-g6825fb5-dirty #1137 [ 4782.624344] 0000000000000009 ffff8800193eb770 ffffffffa04c742a 0000000000000000 [ 4782.627801] ffff8800193eb7a8 ffffffff9d16e55d 00007f2458d89000 ffff880120959600 [ 4782.629283] ffff88012b02c000 ffffea002abeab00 ffff88063118da90 ffff8800193eb7b8 [ 4782.631353] Call Trace: [ 4782.633789] [<ffffffffa04c742a>] dump_stack+0x4e/0x7a [ 4782.634314] [<ffffffff9d16e55d>] warn_slowpath_common+0x7d/0xa0 [ 4782.634877] [<ffffffff9d16e63a>] warn_slowpath_null+0x1a/0x20 [ 4782.635430] [<ffffffff9d315487>] remove_migration_pte+0x3f7/0x420 [ 4782.636042] [<ffffffff9d2e99cf>] rmap_walk+0xef/0x380 [ 4782.636544] [<ffffffff9d3147f1>] remove_migration_ptes+0x41/0x50 [ 4782.637130] [<ffffffff9d315090>] ? __migration_entry_wait.isra.24+0x160/0x160 [ 4782.639928] [<ffffffff9d3154b0>] ? remove_migration_pte+0x420/0x420 [ 4782.640616] [<ffffffff9d31671b>] move_to_new_page+0x16b/0x230 [ 4782.641251] [<ffffffff9d2e9e8c>] ? try_to_unmap+0x6c/0xf0 [ 4782.643950] [<ffffffff9d2e88a0>] ? try_to_unmap_nonlinear+0x5c0/0x5c0 [ 4782.644690] [<ffffffff9d2e70a0>] ? invalid_migration_vma+0x30/0x30 [ 4782.645273] [<ffffffff9d2e82e0>] ? page_remove_rmap+0x320/0x320 [ 4782.646072] [<ffffffff9d31717c>] migrate_pages+0x85c/0x930 [ 4782.646701] [<ffffffff9d2d0e20>] ? isolate_freepages_block+0x410/0x410 [ 4782.647407] [<ffffffff9d2cfa60>] ? arch_local_save_flags+0x30/0x30 [ 4782.648114] [<ffffffff9d2d1803>] compact_zone+0x4d3/0x8a0 [ 4782.650157] [<ffffffff9d2d1c2f>] compact_zone_order+0x5f/0xa0 [ 4782.651014] [<ffffffff9d2d1f87>] try_to_compact_pages+0x127/0x2f0 [ 4782.651656] [<ffffffff9d2b0c98>] __alloc_pages_direct_compact+0x68/0x200 [ 4782.652313] [<ffffffff9d2b17ca>] __alloc_pages_nodemask+0x99a/0xd90 [ 4782.652916] [<ffffffff9d300a1c>] alloc_pages_vma+0x13c/0x270 [ 4782.653618] [<ffffffff9d31d914>] ? do_huge_pmd_wp_page+0x494/0xc90 [ 4782.654487] [<ffffffff9d31d914>] do_huge_pmd_wp_page+0x494/0xc90 [ 4782.656045] [<ffffffff9d320d20>] ? __mem_cgroup_count_vm_event+0xd0/0x240 [ 4782.657089] [<ffffffff9d2dcb7d>] handle_mm_fault+0x8bd/0xc50 [ 4782.660931] [<ffffffff9d1d26e6>] ? __lock_is_held+0x56/0x80 [ 4782.662695] [<ffffffff9d0c7bc7>] __do_page_fault+0x1b7/0x660 [ 4782.663259] [<ffffffff9d1cdc5e>] ? put_lock_stats.isra.13+0xe/0x30 [ 4782.663851] [<ffffffff9d1abf41>] ? vtime_account_user+0x91/0xa0 [ 4782.664419] [<ffffffff9d2a2c35>] ? context_tracking_user_exit+0xb5/0x1b0 [ 4782.665119] [<ffffffff9db6e103>] ? __this_cpu_preempt_check+0x13/0x20 [ 4782.665969] [<ffffffff9d1ce2e2>] ? trace_hardirqs_off_caller+0xe2/0x1b0 [ 4782.666634] [<ffffffff9d0c8141>] trace_do_page_fault+0x51/0x2b0 [ 4782.667257] [<ffffffff9d0bee83>] do_async_page_fault+0x63/0xd0 [ 4782.667871] [<ffffffffa0511018>] async_page_fault+0x28/0x30 Although it wasn't followed by anything else, and I've seen the original issue getting triggered without this WARN showing up, so it seems like a different, unrelated issue? 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-10 12:47 ` Mel Gorman @ 2014-09-10 19:36 ` Hugh Dickins -1 siblings, 0 replies; 86+ messages in thread From: Hugh Dickins @ 2014-09-10 19:36 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Wed, 10 Sep 2014, Mel Gorman wrote: > On Tue, Sep 09, 2014 at 07:45:26PM -0700, Hugh Dickins wrote: > > > > I've been rather assuming that the 9d340902 seen in many of the > > registers in that Aug26 dump is the pte val in question: that's > > SOFT_DIRTY|PROTNONE|RW. The 900s in the latest dumps imply that that 902 was not important. (If any of them are in fact the pte val.) > > > > I think RW on PROTNONE is unusual but not impossible (migration entry > > replacement racing with mprotect setting PROT_NONE, after it's updated > > vm_page_prot, before it's reached the page table). > > At the risk of sounding thick, I need to spell this out because I'm > having trouble seeing exactly what race you are thinking of. > > Migration entry replacement is protected against parallel NUMA hinting > updates by the page table lock (either PMD or PTE level). It's taken by > remove_migration_pte on one side and lock_pte_protection on the other. > > For the mprotect case racing again migration, migration entries are not > present so change_pte_range() should ignore it. On migration completion > the VMA flags determine the permissions of the new PTE. Parallel faults > wait on the migration entry and see the correct value afterwards. > > When creating migration entries, try_to_unmap calls page_check_address > which takes the PTL before doing anything. On the mprotect side, > lock_pte_protection will block before seeing PROTNONE. > > I think the race you are thinking of is a migration entry created for write, > parallel mprotect(PROTNONE) and migration completion. The migration entry > was created for write but remove_migration_pte does not double check the VMA > protections and mmap_sem is not taken for write across a full migration to > protect against changes to vm_page_prot. Yes, the "if (is_write_migration_entry(entry)) pte = pte_mkwrite(pte);" arguably should take the latest value of vma->vm_page_prot into account. > However, change_pte_range checks > for migration entries marked for write under the PTL and marks them read if > one is encountered. The consequence is that we potentially take a spurious > fault to mark the PTE write again after migration completes but I can't > see how that causes a problem as such. Yes, once mprotect's page table walk reaches that pte, it updates it correctly along with all the others nearby (which were not migrated), removing the temporary oddity. > > I'm missing some part of your reasoning that leads to the RW|PROTNONE :( You don't appear to be missing it at all, you are seeing the possibility of an RW|PROTNONE yourself, and how it gets "corrected" afterwards ("corrected" in quotes because without the present bit, it's not an error). > > > But exciting though > > that line of thought is, I cannot actually bring it to a pte_mknuma bug, > > or any bug at all. > > And I wasn't saying that it led to this bug, just that it was an oddity worth thinking about, and worth mentioning to you, in case you could work out a way it might lead to the bug, when I had failed to do so. But we now (almost) know that 902 is irrelevant to this bug anyway. > > On x86, PROTNONE|RW translates as GLOBAL|RW which would be unexpected. It GLOBAL once PRESENT is set, but PROTNONE so long as it is not. > wouldn't cause this bug but it's sufficiently suspicious to be worth > correcting. In case this is the race you're thinking of, the patch is below. > Unfortunately, I cannot see how it would affect this problem but worth > giving a whirl anyway. > > > Mel, no way can it be the cause of this bug - unless Sasha's later > > traces actually show a different stack - but I don't see the call > > to change_prot_numa() from queue_pages_range() sharing the same > > avoidance of PROT_NONE that task_numa_work() has (though it does > > have an outdated comment about PROT_NONE which should be removed). > > So I think that site probably does need PROT_NONE checking added. > > > > That site should have checked PROT_NONE but it can't be the same bug > that trinity is seeing. Minimally trinity is unaware of MPOL_MF_LAZY > according to git grep of the trinity source. Yes, queue_pages_range() is not implicated in any of Sasha's traces. Something to fix, but not relevant to this bug. > > Worth adding this to the debugging mix? It should warn if it encounters > the problem but avoid adding the problematic RW bit. > > ---8<--- > migrate: debug patch to try identify race between migration completion and mprotect > > A migration entry is marked as write if pte_write was true at the > time the entry was created. The VMA protections are not double checked > when migration entries are being removed but mprotect itself will mark > write-migration-entries as read to avoid problems. It means we potentially > take a spurious fault to mark these ptes write again but otherwise it's > harmless. Still, one dump indicates that this situation can actually > happen so this debugging patch spits out a warning if the situation occurs > and hopefully the resulting warning will contain a clue as to how exactly > it happens > > Not-signed-off > --- > mm/migrate.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/mm/migrate.c b/mm/migrate.c > index 09d489c..631725c 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -146,8 +146,16 @@ static int remove_migration_pte(struct page *new, struct vm_area_struct *vma, > pte = pte_mkold(mk_pte(new, vma->vm_page_prot)); > if (pte_swp_soft_dirty(*ptep)) > pte = pte_mksoft_dirty(pte); > - if (is_write_migration_entry(entry)) > - pte = pte_mkwrite(pte); > + if (is_write_migration_entry(entry)) { > + /* > + * This WARN_ON_ONCE is temporary for the purposes of seeing if > + * it's a case encountered by trinity in Sasha's testing > + */ > + if (!(vma->vm_flags & (VM_WRITE))) > + WARN_ON_ONCE(1); > + else > + pte = pte_mkwrite(pte); > + } > #ifdef CONFIG_HUGETLB_PAGE > if (PageHuge(new)) { > pte = pte_mkhuge(pte); > Right, and Sasha reports that that can fire, but he sees the bug with this patch in and without that firing. Consider 902 of no interest, it was just something worth mentioning before we got more info. Hugh ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-10 19:36 ` Hugh Dickins 0 siblings, 0 replies; 86+ messages in thread From: Hugh Dickins @ 2014-09-10 19:36 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Wed, 10 Sep 2014, Mel Gorman wrote: > On Tue, Sep 09, 2014 at 07:45:26PM -0700, Hugh Dickins wrote: > > > > I've been rather assuming that the 9d340902 seen in many of the > > registers in that Aug26 dump is the pte val in question: that's > > SOFT_DIRTY|PROTNONE|RW. The 900s in the latest dumps imply that that 902 was not important. (If any of them are in fact the pte val.) > > > > I think RW on PROTNONE is unusual but not impossible (migration entry > > replacement racing with mprotect setting PROT_NONE, after it's updated > > vm_page_prot, before it's reached the page table). > > At the risk of sounding thick, I need to spell this out because I'm > having trouble seeing exactly what race you are thinking of. > > Migration entry replacement is protected against parallel NUMA hinting > updates by the page table lock (either PMD or PTE level). It's taken by > remove_migration_pte on one side and lock_pte_protection on the other. > > For the mprotect case racing again migration, migration entries are not > present so change_pte_range() should ignore it. On migration completion > the VMA flags determine the permissions of the new PTE. Parallel faults > wait on the migration entry and see the correct value afterwards. > > When creating migration entries, try_to_unmap calls page_check_address > which takes the PTL before doing anything. On the mprotect side, > lock_pte_protection will block before seeing PROTNONE. > > I think the race you are thinking of is a migration entry created for write, > parallel mprotect(PROTNONE) and migration completion. The migration entry > was created for write but remove_migration_pte does not double check the VMA > protections and mmap_sem is not taken for write across a full migration to > protect against changes to vm_page_prot. Yes, the "if (is_write_migration_entry(entry)) pte = pte_mkwrite(pte);" arguably should take the latest value of vma->vm_page_prot into account. > However, change_pte_range checks > for migration entries marked for write under the PTL and marks them read if > one is encountered. The consequence is that we potentially take a spurious > fault to mark the PTE write again after migration completes but I can't > see how that causes a problem as such. Yes, once mprotect's page table walk reaches that pte, it updates it correctly along with all the others nearby (which were not migrated), removing the temporary oddity. > > I'm missing some part of your reasoning that leads to the RW|PROTNONE :( You don't appear to be missing it at all, you are seeing the possibility of an RW|PROTNONE yourself, and how it gets "corrected" afterwards ("corrected" in quotes because without the present bit, it's not an error). > > > But exciting though > > that line of thought is, I cannot actually bring it to a pte_mknuma bug, > > or any bug at all. > > And I wasn't saying that it led to this bug, just that it was an oddity worth thinking about, and worth mentioning to you, in case you could work out a way it might lead to the bug, when I had failed to do so. But we now (almost) know that 902 is irrelevant to this bug anyway. > > On x86, PROTNONE|RW translates as GLOBAL|RW which would be unexpected. It GLOBAL once PRESENT is set, but PROTNONE so long as it is not. > wouldn't cause this bug but it's sufficiently suspicious to be worth > correcting. In case this is the race you're thinking of, the patch is below. > Unfortunately, I cannot see how it would affect this problem but worth > giving a whirl anyway. > > > Mel, no way can it be the cause of this bug - unless Sasha's later > > traces actually show a different stack - but I don't see the call > > to change_prot_numa() from queue_pages_range() sharing the same > > avoidance of PROT_NONE that task_numa_work() has (though it does > > have an outdated comment about PROT_NONE which should be removed). > > So I think that site probably does need PROT_NONE checking added. > > > > That site should have checked PROT_NONE but it can't be the same bug > that trinity is seeing. Minimally trinity is unaware of MPOL_MF_LAZY > according to git grep of the trinity source. Yes, queue_pages_range() is not implicated in any of Sasha's traces. Something to fix, but not relevant to this bug. > > Worth adding this to the debugging mix? It should warn if it encounters > the problem but avoid adding the problematic RW bit. > > ---8<--- > migrate: debug patch to try identify race between migration completion and mprotect > > A migration entry is marked as write if pte_write was true at the > time the entry was created. The VMA protections are not double checked > when migration entries are being removed but mprotect itself will mark > write-migration-entries as read to avoid problems. It means we potentially > take a spurious fault to mark these ptes write again but otherwise it's > harmless. Still, one dump indicates that this situation can actually > happen so this debugging patch spits out a warning if the situation occurs > and hopefully the resulting warning will contain a clue as to how exactly > it happens > > Not-signed-off > --- > mm/migrate.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/mm/migrate.c b/mm/migrate.c > index 09d489c..631725c 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -146,8 +146,16 @@ static int remove_migration_pte(struct page *new, struct vm_area_struct *vma, > pte = pte_mkold(mk_pte(new, vma->vm_page_prot)); > if (pte_swp_soft_dirty(*ptep)) > pte = pte_mksoft_dirty(pte); > - if (is_write_migration_entry(entry)) > - pte = pte_mkwrite(pte); > + if (is_write_migration_entry(entry)) { > + /* > + * This WARN_ON_ONCE is temporary for the purposes of seeing if > + * it's a case encountered by trinity in Sasha's testing > + */ > + if (!(vma->vm_flags & (VM_WRITE))) > + WARN_ON_ONCE(1); > + else > + pte = pte_mkwrite(pte); > + } > #ifdef CONFIG_HUGETLB_PAGE > if (PageHuge(new)) { > pte = pte_mkhuge(pte); > Right, and Sasha reports that that can fire, but he sees the bug with this patch in and without that firing. Consider 902 of no interest, it was just something worth mentioning before we got more info. Hugh -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-10 19:36 ` Hugh Dickins @ 2014-09-11 2:43 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-11 2:43 UTC (permalink / raw) To: Hugh Dickins, Mel Gorman Cc: linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/10/2014 03:36 PM, Hugh Dickins wrote: >> migrate: debug patch to try identify race between migration completion and mprotect >> > >> > A migration entry is marked as write if pte_write was true at the >> > time the entry was created. The VMA protections are not double checked >> > when migration entries are being removed but mprotect itself will mark >> > write-migration-entries as read to avoid problems. It means we potentially >> > take a spurious fault to mark these ptes write again but otherwise it's >> > harmless. Still, one dump indicates that this situation can actually >> > happen so this debugging patch spits out a warning if the situation occurs >> > and hopefully the resulting warning will contain a clue as to how exactly >> > it happens >> > >> > Not-signed-off >> > --- >> > mm/migrate.c | 12 ++++++++++-- >> > 1 file changed, 10 insertions(+), 2 deletions(-) >> > >> > diff --git a/mm/migrate.c b/mm/migrate.c >> > index 09d489c..631725c 100644 >> > --- a/mm/migrate.c >> > +++ b/mm/migrate.c >> > @@ -146,8 +146,16 @@ static int remove_migration_pte(struct page *new, struct vm_area_struct *vma, >> > pte = pte_mkold(mk_pte(new, vma->vm_page_prot)); >> > if (pte_swp_soft_dirty(*ptep)) >> > pte = pte_mksoft_dirty(pte); >> > - if (is_write_migration_entry(entry)) >> > - pte = pte_mkwrite(pte); >> > + if (is_write_migration_entry(entry)) { >> > + /* >> > + * This WARN_ON_ONCE is temporary for the purposes of seeing if >> > + * it's a case encountered by trinity in Sasha's testing >> > + */ >> > + if (!(vma->vm_flags & (VM_WRITE))) >> > + WARN_ON_ONCE(1); >> > + else >> > + pte = pte_mkwrite(pte); >> > + } >> > #ifdef CONFIG_HUGETLB_PAGE >> > if (PageHuge(new)) { >> > pte = pte_mkhuge(pte); >> > > Right, and Sasha reports that that can fire, but he sees the bug > with this patch in and without that firing. I've changed that WARN_ON_ONCE() to a VM_BUG_ON_VMA() to get some useful VMA information out, and got the following: [ 4018.870776] vma ffff8801a0f1e800 start 00007f3fd0ca7000 end 00007f3fd16a7000 [ 4018.870776] next ffff8804e1b89800 prev ffff88008cd9a000 mm ffff88054b17d000 [ 4018.870776] prot 120 anon_vma ffff880bc858a200 vm_ops (null) [ 4018.870776] pgoff 41bc8 file (null) private_data (null) [ 4018.879731] flags: 0x8100070(mayread|maywrite|mayexec|account) [ 4018.881324] ------------[ cut here ]------------ [ 4018.882612] kernel BUG at mm/migrate.c:155! [ 4018.883649] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 4018.889647] Dumping ftrace buffer: [ 4018.890323] (ftrace buffer empty) [ 4018.890323] Modules linked in: [ 4018.890323] CPU: 4 PID: 9966 Comm: trinity-main Tainted: G W 3.17.0-rc4-next-20140910-sasha-00042-ga4bad9b-dirty #1140 [ 4018.890323] task: ffff880695b83000 ti: ffff880560c44000 task.ti: ffff880560c44000 [ 4018.890323] RIP: 0010:[<ffffffff9b2fd4c1>] [<ffffffff9b2fd4c1>] remove_migration_pte+0x3e1/0x3f0 [ 4018.890323] RSP: 0000:ffff880560c477c8 EFLAGS: 00010292 [ 4018.890323] RAX: 0000000000000001 RBX: 00007f3fd129b000 RCX: 0000000000000000 [ 4018.890323] RDX: 0000000000000001 RSI: ffffffff9e4ba395 RDI: 0000000000000001 [ 4018.890323] RBP: ffff880560c47800 R08: 0000000000000001 R09: 0000000000000001 [ 4018.890323] R10: 0000000000045401 R11: 0000000000000001 R12: ffff8801a0f1e800 [ 4018.890323] R13: ffff88054b17d000 R14: ffffea000478eb40 R15: ffff880122bcf070 [ 4018.890323] FS: 00007f3fd55bb700(0000) GS:ffff8803d6a00000(0000) knlGS:0000000000000000 [ 4018.890323] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 4018.890323] CR2: 0000000000fcbca8 CR3: 0000000561bab000 CR4: 00000000000006a0 [ 4018.890323] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4018.890323] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 [ 4018.890323] Stack: [ 4018.890323] ffffea00046ed980 ffff88011079c4d8 ffffea000478eb40 ffff880560c47858 [ 4018.890323] ffff88019fde0330 00000000000421bc ffff8801a0f1e800 ffff880560c47848 [ 4018.890323] ffffffff9b2d1b0f ffff880bc858a200 ffff880560c47850 ffffea000478eb40 [ 4018.890323] Call Trace: [ 4018.890323] [<ffffffff9b2d1b0f>] rmap_walk+0x22f/0x380 [ 4018.890323] [<ffffffff9b2fc841>] remove_migration_ptes+0x41/0x50 [ 4018.890323] [<ffffffff9b2fd0e0>] ? __migration_entry_wait.isra.24+0x160/0x160 [ 4018.890323] [<ffffffff9b2fd4d0>] ? remove_migration_pte+0x3f0/0x3f0 [ 4018.890323] [<ffffffff9b2fe73b>] move_to_new_page+0x16b/0x230 [ 4018.890323] [<ffffffff9b2d1e8c>] ? try_to_unmap+0x6c/0xf0 [ 4018.890323] [<ffffffff9b2d08a0>] ? try_to_unmap_nonlinear+0x5c0/0x5c0 [ 4018.890323] [<ffffffff9b2cf0a0>] ? invalid_migration_vma+0x30/0x30 [ 4018.890323] [<ffffffff9b2d02e0>] ? page_remove_rmap+0x320/0x320 [ 4018.890323] [<ffffffff9b2ff19c>] migrate_pages+0x85c/0x930 [ 4018.890323] [<ffffffff9b2b8e20>] ? isolate_freepages_block+0x410/0x410 [ 4018.890323] [<ffffffff9b2b7a60>] ? arch_local_save_flags+0x30/0x30 [ 4018.890323] [<ffffffff9b2b9803>] compact_zone+0x4d3/0x8a0 [ 4018.890323] [<ffffffff9b2b9c2f>] compact_zone_order+0x5f/0xa0 [ 4018.890323] [<ffffffff9b2b9f87>] try_to_compact_pages+0x127/0x2f0 [ 4018.890323] [<ffffffff9b298c98>] __alloc_pages_direct_compact+0x68/0x200 [ 4018.890323] [<ffffffff9b2995af>] __alloc_pages_nodemask+0x77f/0xd90 [ 4018.890323] [<ffffffff9b192fad>] ? sched_clock_local+0x1d/0x90 [ 4018.890323] [<ffffffff9b2e8a1c>] alloc_pages_vma+0x13c/0x270 [ 4018.890323] [<ffffffff9b305934>] ? do_huge_pmd_wp_page+0x494/0xc90 [ 4018.890323] [<ffffffff9b305934>] do_huge_pmd_wp_page+0x494/0xc90 [ 4018.890323] [<ffffffff9b308d40>] ? __mem_cgroup_count_vm_event+0xd0/0x240 [ 4018.890323] [<ffffffff9b2c4b7d>] handle_mm_fault+0x8bd/0xc50 [ 4018.890323] [<ffffffff9b1ba6e6>] ? __lock_is_held+0x56/0x80 [ 4018.890323] [<ffffffff9b0afbc7>] __do_page_fault+0x1b7/0x660 [ 4018.890323] [<ffffffff9b1b5c5e>] ? put_lock_stats.isra.13+0xe/0x30 [ 4018.890323] [<ffffffff9b193f41>] ? vtime_account_user+0x91/0xa0 [ 4018.890323] [<ffffffff9b28ac35>] ? context_tracking_user_exit+0xb5/0x1b0 [ 4018.890323] [<ffffffff9bb55d33>] ? __this_cpu_preempt_check+0x13/0x20 [ 4018.890323] [<ffffffff9b1b62e2>] ? trace_hardirqs_off_caller+0xe2/0x1b0 [ 4018.890323] [<ffffffff9b0b0141>] trace_do_page_fault+0x51/0x2b0 [ 4018.890323] [<ffffffff9b0a6e83>] do_async_page_fault+0x63/0xd0 [ 4018.890323] [<ffffffff9e4bccf8>] async_page_fault+0x28/0x30 [ 4018.890323] Code: 0f 0b 48 c7 c6 b0 f2 71 9f 4c 89 f7 e8 b9 79 f9 ff 0f 0b 48 83 c9 02 41 f6 44 24 50 02 0f 85 70 fe ff ff 4c 89 e7 e8 af 4a f9 ff <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 [ 4018.890323] RIP [<ffffffff9b2fd4c1>] remove_migration_pte+0x3e1/0x3f0 [ 4018.890323] RSP <ffff880560c477c8> And from a different log: [ 2035.602565] vma ffff88054b666c00 start 00007f561ffad000 end 00007f56203ad000 [ 2035.602565] next ffff88054b665a00 prev ffff8801f7a31800 mm ffff8804f207a000 [ 2035.602565] prot 120 anon_vma (null) vm_ops ffffffffb5671e80 [ 2035.602565] pgoff 0 file ffff88054b430a80 private_data (null) [ 2035.608469] flags: 0x80000f8(shared|mayread|maywrite|mayexec|mayshare) And on a maybe related note, I've started seeing the following today. It may be because we fixed mbind() in trinity but it could also be related to this issue (free_pgtables() is in the call chain). If you don't think it has anything to do with it let me know and I'll start a new thread: [ 1195.996803] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1196.001744] IP: __rb_erase_color (include/linux/rbtree_augmented.h:107 lib/rbtree.c:229 lib/rbtree.c:367) [ 1196.001744] PGD 196787067 PUD 117522067 PMD 0 [ 1196.001744] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 1196.001744] Dumping ftrace buffer: [ 1196.001744] (ftrace buffer empty) [ 1196.001744] Modules linked in: [ 1196.001744] CPU: 5 PID: 5724 Comm: trinity-c890 Not tainted 3.17.0-rc4-next-20140910-sasha-00042-ga4bad9b-dirty #1140 [ 1196.001744] task: ffff88024207b000 ti: ffff8808b25e0000 task.ti: ffff8808b25e0000 [ 1196.001744] RIP: __rb_erase_color (include/linux/rbtree_augmented.h:107 lib/rbtree.c:229 lib/rbtree.c:367) [ 1196.001744] RSP: 0018:ffff8808b25e3d18 EFLAGS: 00010286 [ 1196.001744] RAX: ffff8808890ed059 RBX: ffff88091f75f458 RCX: 0000000000000000 [ 1196.001744] RDX: 0000000000000000 RSI: ffff8800b83396c8 RDI: ffff8808890ed058 [ 1196.001744] RBP: ffff8808b25e3d40 R08: ffff8808890ed058 R09: 0000000000000000 [ 1196.001744] R10: 0000000000000000 R11: ffff88085697d658 R12: ffff8808890ed058 [ 1196.001744] R13: ffffffff912ba700 R14: ffff8800b83396c8 R15: 0000000000000000 [ 1196.001744] FS: 00007f00e4458700(0000) GS:ffff880492c00000(0000) knlGS:0000000000000000 [ 1196.001744] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1196.001744] CR2: 0000000000000000 CR3: 0000000196786000 CR4: 00000000000006a0 [ 1196.001744] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1196.001744] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000070602 [ 1196.001744] Stack: [ 1196.001744] ffff88085697d600 ffff8800b5d13480 ffff8800b83396e0 ffff8800b8339660 [ 1196.001744] ffff88085697d600 ffff8808b25e3d58 ffffffff912ba9e4 ffff88085697d600 [ 1196.001744] ffff8808b25e3d78 ffffffff912c8446 ffff88085697d600 ffff8800b5d13480 [ 1196.001744] Call Trace: [ 1196.001744] vma_interval_tree_remove (mm/interval_tree.c:24) [ 1196.001744] __remove_shared_vm_struct (mm/mmap.c:232) [ 1196.001744] unlink_file_vma (mm/mmap.c:246) [ 1196.001744] free_pgtables (mm/memory.c:547) [ 1196.001744] exit_mmap (mm/mmap.c:2826) [ 1196.001744] mmput (kernel/fork.c:654) [ 1196.001744] do_exit (./arch/x86/include/asm/thread_info.h:168 kernel/exit.c:461 kernel/exit.c:746) [ 1196.001744] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63) [ 1196.001744] ? trace_hardirqs_on (kernel/locking/lockdep.c:2609) [ 1196.001744] do_group_exit (./arch/x86/include/asm/current.h:14 kernel/exit.c:874) [ 1196.001744] SyS_exit_group (kernel/exit.c:900) [ 1196.001744] tracesys (arch/x86/kernel/entry_64.S:542) [ 1196.001744] Code: e2 49 89 c4 49 8b 5c 24 08 48 39 d3 0f 84 e2 00 00 00 f6 03 01 75 ad 4c 8b 7b 10 4c 89 e0 48 83 c8 01 4d 89 7c 24 08 4c 89 63 10 <49> 89 07 49 8b 04 24 48 89 03 48 83 e0 fc 49 89 1c 24 0f 84 69 All code ======== 0: e2 49 loop 0x4b 2: 89 c4 mov %eax,%esp 4: 49 8b 5c 24 08 mov 0x8(%r12),%rbx 9: 48 39 d3 cmp %rdx,%rbx c: 0f 84 e2 00 00 00 je 0xf4 12: f6 03 01 testb $0x1,(%rbx) 15: 75 ad jne 0xffffffffffffffc4 17: 4c 8b 7b 10 mov 0x10(%rbx),%r15 1b: 4c 89 e0 mov %r12,%rax 1e: 48 83 c8 01 or $0x1,%rax 22: 4d 89 7c 24 08 mov %r15,0x8(%r12) 27: 4c 89 63 10 mov %r12,0x10(%rbx) 2b:* 49 89 07 mov %rax,(%r15) <-- trapping instruction 2e: 49 8b 04 24 mov (%r12),%rax 32: 48 89 03 mov %rax,(%rbx) 35: 48 83 e0 fc and $0xfffffffffffffffc,%rax 39: 49 89 1c 24 mov %rbx,(%r12) 3d: 0f .byte 0xf 3e: 84 69 00 test %ch,0x0(%rcx) Code starting with the faulting instruction =========================================== 0: 49 89 07 mov %rax,(%r15) 3: 49 8b 04 24 mov (%r12),%rax 7: 48 89 03 mov %rax,(%rbx) a: 48 83 e0 fc and $0xfffffffffffffffc,%rax e: 49 89 1c 24 mov %rbx,(%r12) 12: 0f .byte 0xf 13: 84 69 00 test %ch,0x0(%rcx) [ 1196.001744] RIP __rb_erase_color (include/linux/rbtree_augmented.h:107 lib/rbtree.c:229 lib/rbtree.c:367) [ 1196.001744] RSP <ffff8808b25e3d18> [ 1196.001744] CR2: 0000000000000000 [ 1196.001744] ---[ end trace 67e0103d243f3c04 ]--- [ 1196.050031] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 1196.050031] IP: __rb_insert_augmented (lib/rbtree.c:94 lib/rbtree.c:411) [ 1196.050031] PGD a3ea09067 PUD a69b38067 PMD 0 [ 1196.050031] Oops: 0000 [#2] PREEMPT SMP DEBUG_PAGEALLOC [ 1196.050031] Dumping ftrace buffer: [ 1196.050031] (ftrace buffer empty) [ 1196.050031] Modules linked in: [ 1196.050031] CPU: 3 PID: 5688 Comm: trinity-c802 Tainted: G D 3.17.0-rc4-next-20140910-sasha-00042-ga4bad9b-dirty #1140 [ 1196.050031] task: ffff880a508f8000 ti: ffff880a6950c000 task.ti: ffff880a6950c000 [ 1196.050031] RIP: __rb_insert_augmented (lib/rbtree.c:94 lib/rbtree.c:411) [ 1196.050031] RSP: 0018:ffff880a6950fd68 EFLAGS: 00010246 [ 1196.050031] RAX: ffff88091f75a058 RBX: 0000000000000000 RCX: 0000000000000000 [ 1196.050031] RDX: ffffffff912ba700 RSI: ffff8800b4cb3718 RDI: ffff8802d786ca58 [ 1196.050031] RBP: ffff880a6950fd90 R08: ffff8802d786ca00 R09: ffff8800b4cb3718 [ 1196.050031] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8801fd067400 [ 1196.050031] R13: ffff8802d786ca00 R14: ffff8800b4cb3718 R15: 00007f00e44589d0 [ 1196.050031] FS: 00007f00e4458700(0000) GS:ffff88031ac00000(0000) knlGS:0000000000000000 [ 1196.050031] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1196.050031] CR2: 0000000000000008 CR3: 0000000a62597000 CR4: 00000000000006a0 [ 1196.050031] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1196.050031] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000070602 [ 1196.050031] Stack: [ 1196.050031] ffffffff9115499e ffff88028bc7a000 ffff8801fd067400 ffff8802d786ca00 [ 1196.050031] ffff8800b4cb3730 ffff880a6950fda0 ffffffff912babfd ffff880a6950fe70 [ 1196.050031] ffffffff91154a77 ffff8800b4cb36b0 000000003ebe3540 0000000000000000 [ 1196.050031] Call Trace: [ 1196.050031] ? copy_process (kernel/fork.c:409 kernel/fork.c:859 kernel/fork.c:913 kernel/fork.c:1381) [ 1196.050031] vma_interval_tree_insert_after (mm/interval_tree.c:60) [ 1196.050031] copy_process (kernel/fork.c:442 kernel/fork.c:859 kernel/fork.c:913 kernel/fork.c:1381) [ 1196.050031] do_fork (kernel/fork.c:1644) [ 1196.050031] ? context_tracking_user_exit (./arch/x86/include/asm/paravirt.h:809 (discriminator 2) kernel/context_tracking.c:184 (discriminator 2)) [ 1196.050031] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63) [ 1196.050031] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2559 kernel/locking/lockdep.c:2601) [ 1196.050031] ? trace_hardirqs_on (kernel/locking/lockdep.c:2609) [ 1196.050031] SyS_clone (kernel/fork.c:1733) [ 1196.050031] stub_clone (arch/x86/kernel/entry_64.S:637) [ 1196.050031] ? tracesys (arch/x86/kernel/entry_64.S:542) [ 1196.050031] Code: ff ff 0f 1f 00 48 8b 07 48 85 c0 0f 84 a4 01 00 00 55 48 89 e5 41 56 49 89 f6 41 55 41 54 53 48 83 ec 08 48 8b 18 f6 c3 01 75 6b <48> 8b 4b 08 49 89 d8 48 39 c8 0f 84 a5 00 00 00 48 85 c9 74 05 All code ======== 0: ff (bad) 1: ff 0f decl (%rdi) 3: 1f (bad) 4: 00 48 8b add %cl,-0x75(%rax) 7: 07 (bad) 8: 48 85 c0 test %rax,%rax b: 0f 84 a4 01 00 00 je 0x1b5 11: 55 push %rbp 12: 48 89 e5 mov %rsp,%rbp 15: 41 56 push %r14 17: 49 89 f6 mov %rsi,%r14 1a: 41 55 push %r13 1c: 41 54 push %r12 1e: 53 push %rbx 1f: 48 83 ec 08 sub $0x8,%rsp 23: 48 8b 18 mov (%rax),%rbx 26: f6 c3 01 test $0x1,%bl 29: 75 6b jne 0x96 2b:* 48 8b 4b 08 mov 0x8(%rbx),%rcx <-- trapping instruction 2f: 49 89 d8 mov %rbx,%r8 32: 48 39 c8 cmp %rcx,%rax 35: 0f 84 a5 00 00 00 je 0xe0 3b: 48 85 c9 test %rcx,%rcx 3e: 74 05 je 0x45 ... Code starting with the faulting instruction =========================================== 0: 48 8b 4b 08 mov 0x8(%rbx),%rcx 4: 49 89 d8 mov %rbx,%r8 7: 48 39 c8 cmp %rcx,%rax a: 0f 84 a5 00 00 00 je 0xb5 10: 48 85 c9 test %rcx,%rcx 13: 74 05 je 0x1a ... [ 1196.050031] RIP __rb_insert_augmented (lib/rbtree.c:94 lib/rbtree.c:411) [ 1196.050031] RSP <ffff880a6950fd68> [ 1196.050031] CR2: 0000000000000008 Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-11 2:43 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-11 2:43 UTC (permalink / raw) To: Hugh Dickins, Mel Gorman Cc: linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/10/2014 03:36 PM, Hugh Dickins wrote: >> migrate: debug patch to try identify race between migration completion and mprotect >> > >> > A migration entry is marked as write if pte_write was true at the >> > time the entry was created. The VMA protections are not double checked >> > when migration entries are being removed but mprotect itself will mark >> > write-migration-entries as read to avoid problems. It means we potentially >> > take a spurious fault to mark these ptes write again but otherwise it's >> > harmless. Still, one dump indicates that this situation can actually >> > happen so this debugging patch spits out a warning if the situation occurs >> > and hopefully the resulting warning will contain a clue as to how exactly >> > it happens >> > >> > Not-signed-off >> > --- >> > mm/migrate.c | 12 ++++++++++-- >> > 1 file changed, 10 insertions(+), 2 deletions(-) >> > >> > diff --git a/mm/migrate.c b/mm/migrate.c >> > index 09d489c..631725c 100644 >> > --- a/mm/migrate.c >> > +++ b/mm/migrate.c >> > @@ -146,8 +146,16 @@ static int remove_migration_pte(struct page *new, struct vm_area_struct *vma, >> > pte = pte_mkold(mk_pte(new, vma->vm_page_prot)); >> > if (pte_swp_soft_dirty(*ptep)) >> > pte = pte_mksoft_dirty(pte); >> > - if (is_write_migration_entry(entry)) >> > - pte = pte_mkwrite(pte); >> > + if (is_write_migration_entry(entry)) { >> > + /* >> > + * This WARN_ON_ONCE is temporary for the purposes of seeing if >> > + * it's a case encountered by trinity in Sasha's testing >> > + */ >> > + if (!(vma->vm_flags & (VM_WRITE))) >> > + WARN_ON_ONCE(1); >> > + else >> > + pte = pte_mkwrite(pte); >> > + } >> > #ifdef CONFIG_HUGETLB_PAGE >> > if (PageHuge(new)) { >> > pte = pte_mkhuge(pte); >> > > Right, and Sasha reports that that can fire, but he sees the bug > with this patch in and without that firing. I've changed that WARN_ON_ONCE() to a VM_BUG_ON_VMA() to get some useful VMA information out, and got the following: [ 4018.870776] vma ffff8801a0f1e800 start 00007f3fd0ca7000 end 00007f3fd16a7000 [ 4018.870776] next ffff8804e1b89800 prev ffff88008cd9a000 mm ffff88054b17d000 [ 4018.870776] prot 120 anon_vma ffff880bc858a200 vm_ops (null) [ 4018.870776] pgoff 41bc8 file (null) private_data (null) [ 4018.879731] flags: 0x8100070(mayread|maywrite|mayexec|account) [ 4018.881324] ------------[ cut here ]------------ [ 4018.882612] kernel BUG at mm/migrate.c:155! [ 4018.883649] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 4018.889647] Dumping ftrace buffer: [ 4018.890323] (ftrace buffer empty) [ 4018.890323] Modules linked in: [ 4018.890323] CPU: 4 PID: 9966 Comm: trinity-main Tainted: G W 3.17.0-rc4-next-20140910-sasha-00042-ga4bad9b-dirty #1140 [ 4018.890323] task: ffff880695b83000 ti: ffff880560c44000 task.ti: ffff880560c44000 [ 4018.890323] RIP: 0010:[<ffffffff9b2fd4c1>] [<ffffffff9b2fd4c1>] remove_migration_pte+0x3e1/0x3f0 [ 4018.890323] RSP: 0000:ffff880560c477c8 EFLAGS: 00010292 [ 4018.890323] RAX: 0000000000000001 RBX: 00007f3fd129b000 RCX: 0000000000000000 [ 4018.890323] RDX: 0000000000000001 RSI: ffffffff9e4ba395 RDI: 0000000000000001 [ 4018.890323] RBP: ffff880560c47800 R08: 0000000000000001 R09: 0000000000000001 [ 4018.890323] R10: 0000000000045401 R11: 0000000000000001 R12: ffff8801a0f1e800 [ 4018.890323] R13: ffff88054b17d000 R14: ffffea000478eb40 R15: ffff880122bcf070 [ 4018.890323] FS: 00007f3fd55bb700(0000) GS:ffff8803d6a00000(0000) knlGS:0000000000000000 [ 4018.890323] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 4018.890323] CR2: 0000000000fcbca8 CR3: 0000000561bab000 CR4: 00000000000006a0 [ 4018.890323] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4018.890323] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 [ 4018.890323] Stack: [ 4018.890323] ffffea00046ed980 ffff88011079c4d8 ffffea000478eb40 ffff880560c47858 [ 4018.890323] ffff88019fde0330 00000000000421bc ffff8801a0f1e800 ffff880560c47848 [ 4018.890323] ffffffff9b2d1b0f ffff880bc858a200 ffff880560c47850 ffffea000478eb40 [ 4018.890323] Call Trace: [ 4018.890323] [<ffffffff9b2d1b0f>] rmap_walk+0x22f/0x380 [ 4018.890323] [<ffffffff9b2fc841>] remove_migration_ptes+0x41/0x50 [ 4018.890323] [<ffffffff9b2fd0e0>] ? __migration_entry_wait.isra.24+0x160/0x160 [ 4018.890323] [<ffffffff9b2fd4d0>] ? remove_migration_pte+0x3f0/0x3f0 [ 4018.890323] [<ffffffff9b2fe73b>] move_to_new_page+0x16b/0x230 [ 4018.890323] [<ffffffff9b2d1e8c>] ? try_to_unmap+0x6c/0xf0 [ 4018.890323] [<ffffffff9b2d08a0>] ? try_to_unmap_nonlinear+0x5c0/0x5c0 [ 4018.890323] [<ffffffff9b2cf0a0>] ? invalid_migration_vma+0x30/0x30 [ 4018.890323] [<ffffffff9b2d02e0>] ? page_remove_rmap+0x320/0x320 [ 4018.890323] [<ffffffff9b2ff19c>] migrate_pages+0x85c/0x930 [ 4018.890323] [<ffffffff9b2b8e20>] ? isolate_freepages_block+0x410/0x410 [ 4018.890323] [<ffffffff9b2b7a60>] ? arch_local_save_flags+0x30/0x30 [ 4018.890323] [<ffffffff9b2b9803>] compact_zone+0x4d3/0x8a0 [ 4018.890323] [<ffffffff9b2b9c2f>] compact_zone_order+0x5f/0xa0 [ 4018.890323] [<ffffffff9b2b9f87>] try_to_compact_pages+0x127/0x2f0 [ 4018.890323] [<ffffffff9b298c98>] __alloc_pages_direct_compact+0x68/0x200 [ 4018.890323] [<ffffffff9b2995af>] __alloc_pages_nodemask+0x77f/0xd90 [ 4018.890323] [<ffffffff9b192fad>] ? sched_clock_local+0x1d/0x90 [ 4018.890323] [<ffffffff9b2e8a1c>] alloc_pages_vma+0x13c/0x270 [ 4018.890323] [<ffffffff9b305934>] ? do_huge_pmd_wp_page+0x494/0xc90 [ 4018.890323] [<ffffffff9b305934>] do_huge_pmd_wp_page+0x494/0xc90 [ 4018.890323] [<ffffffff9b308d40>] ? __mem_cgroup_count_vm_event+0xd0/0x240 [ 4018.890323] [<ffffffff9b2c4b7d>] handle_mm_fault+0x8bd/0xc50 [ 4018.890323] [<ffffffff9b1ba6e6>] ? __lock_is_held+0x56/0x80 [ 4018.890323] [<ffffffff9b0afbc7>] __do_page_fault+0x1b7/0x660 [ 4018.890323] [<ffffffff9b1b5c5e>] ? put_lock_stats.isra.13+0xe/0x30 [ 4018.890323] [<ffffffff9b193f41>] ? vtime_account_user+0x91/0xa0 [ 4018.890323] [<ffffffff9b28ac35>] ? context_tracking_user_exit+0xb5/0x1b0 [ 4018.890323] [<ffffffff9bb55d33>] ? __this_cpu_preempt_check+0x13/0x20 [ 4018.890323] [<ffffffff9b1b62e2>] ? trace_hardirqs_off_caller+0xe2/0x1b0 [ 4018.890323] [<ffffffff9b0b0141>] trace_do_page_fault+0x51/0x2b0 [ 4018.890323] [<ffffffff9b0a6e83>] do_async_page_fault+0x63/0xd0 [ 4018.890323] [<ffffffff9e4bccf8>] async_page_fault+0x28/0x30 [ 4018.890323] Code: 0f 0b 48 c7 c6 b0 f2 71 9f 4c 89 f7 e8 b9 79 f9 ff 0f 0b 48 83 c9 02 41 f6 44 24 50 02 0f 85 70 fe ff ff 4c 89 e7 e8 af 4a f9 ff <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 [ 4018.890323] RIP [<ffffffff9b2fd4c1>] remove_migration_pte+0x3e1/0x3f0 [ 4018.890323] RSP <ffff880560c477c8> And from a different log: [ 2035.602565] vma ffff88054b666c00 start 00007f561ffad000 end 00007f56203ad000 [ 2035.602565] next ffff88054b665a00 prev ffff8801f7a31800 mm ffff8804f207a000 [ 2035.602565] prot 120 anon_vma (null) vm_ops ffffffffb5671e80 [ 2035.602565] pgoff 0 file ffff88054b430a80 private_data (null) [ 2035.608469] flags: 0x80000f8(shared|mayread|maywrite|mayexec|mayshare) And on a maybe related note, I've started seeing the following today. It may be because we fixed mbind() in trinity but it could also be related to this issue (free_pgtables() is in the call chain). If you don't think it has anything to do with it let me know and I'll start a new thread: [ 1195.996803] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1196.001744] IP: __rb_erase_color (include/linux/rbtree_augmented.h:107 lib/rbtree.c:229 lib/rbtree.c:367) [ 1196.001744] PGD 196787067 PUD 117522067 PMD 0 [ 1196.001744] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 1196.001744] Dumping ftrace buffer: [ 1196.001744] (ftrace buffer empty) [ 1196.001744] Modules linked in: [ 1196.001744] CPU: 5 PID: 5724 Comm: trinity-c890 Not tainted 3.17.0-rc4-next-20140910-sasha-00042-ga4bad9b-dirty #1140 [ 1196.001744] task: ffff88024207b000 ti: ffff8808b25e0000 task.ti: ffff8808b25e0000 [ 1196.001744] RIP: __rb_erase_color (include/linux/rbtree_augmented.h:107 lib/rbtree.c:229 lib/rbtree.c:367) [ 1196.001744] RSP: 0018:ffff8808b25e3d18 EFLAGS: 00010286 [ 1196.001744] RAX: ffff8808890ed059 RBX: ffff88091f75f458 RCX: 0000000000000000 [ 1196.001744] RDX: 0000000000000000 RSI: ffff8800b83396c8 RDI: ffff8808890ed058 [ 1196.001744] RBP: ffff8808b25e3d40 R08: ffff8808890ed058 R09: 0000000000000000 [ 1196.001744] R10: 0000000000000000 R11: ffff88085697d658 R12: ffff8808890ed058 [ 1196.001744] R13: ffffffff912ba700 R14: ffff8800b83396c8 R15: 0000000000000000 [ 1196.001744] FS: 00007f00e4458700(0000) GS:ffff880492c00000(0000) knlGS:0000000000000000 [ 1196.001744] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1196.001744] CR2: 0000000000000000 CR3: 0000000196786000 CR4: 00000000000006a0 [ 1196.001744] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1196.001744] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000070602 [ 1196.001744] Stack: [ 1196.001744] ffff88085697d600 ffff8800b5d13480 ffff8800b83396e0 ffff8800b8339660 [ 1196.001744] ffff88085697d600 ffff8808b25e3d58 ffffffff912ba9e4 ffff88085697d600 [ 1196.001744] ffff8808b25e3d78 ffffffff912c8446 ffff88085697d600 ffff8800b5d13480 [ 1196.001744] Call Trace: [ 1196.001744] vma_interval_tree_remove (mm/interval_tree.c:24) [ 1196.001744] __remove_shared_vm_struct (mm/mmap.c:232) [ 1196.001744] unlink_file_vma (mm/mmap.c:246) [ 1196.001744] free_pgtables (mm/memory.c:547) [ 1196.001744] exit_mmap (mm/mmap.c:2826) [ 1196.001744] mmput (kernel/fork.c:654) [ 1196.001744] do_exit (./arch/x86/include/asm/thread_info.h:168 kernel/exit.c:461 kernel/exit.c:746) [ 1196.001744] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63) [ 1196.001744] ? trace_hardirqs_on (kernel/locking/lockdep.c:2609) [ 1196.001744] do_group_exit (./arch/x86/include/asm/current.h:14 kernel/exit.c:874) [ 1196.001744] SyS_exit_group (kernel/exit.c:900) [ 1196.001744] tracesys (arch/x86/kernel/entry_64.S:542) [ 1196.001744] Code: e2 49 89 c4 49 8b 5c 24 08 48 39 d3 0f 84 e2 00 00 00 f6 03 01 75 ad 4c 8b 7b 10 4c 89 e0 48 83 c8 01 4d 89 7c 24 08 4c 89 63 10 <49> 89 07 49 8b 04 24 48 89 03 48 83 e0 fc 49 89 1c 24 0f 84 69 All code ======== 0: e2 49 loop 0x4b 2: 89 c4 mov %eax,%esp 4: 49 8b 5c 24 08 mov 0x8(%r12),%rbx 9: 48 39 d3 cmp %rdx,%rbx c: 0f 84 e2 00 00 00 je 0xf4 12: f6 03 01 testb $0x1,(%rbx) 15: 75 ad jne 0xffffffffffffffc4 17: 4c 8b 7b 10 mov 0x10(%rbx),%r15 1b: 4c 89 e0 mov %r12,%rax 1e: 48 83 c8 01 or $0x1,%rax 22: 4d 89 7c 24 08 mov %r15,0x8(%r12) 27: 4c 89 63 10 mov %r12,0x10(%rbx) 2b:* 49 89 07 mov %rax,(%r15) <-- trapping instruction 2e: 49 8b 04 24 mov (%r12),%rax 32: 48 89 03 mov %rax,(%rbx) 35: 48 83 e0 fc and $0xfffffffffffffffc,%rax 39: 49 89 1c 24 mov %rbx,(%r12) 3d: 0f .byte 0xf 3e: 84 69 00 test %ch,0x0(%rcx) Code starting with the faulting instruction =========================================== 0: 49 89 07 mov %rax,(%r15) 3: 49 8b 04 24 mov (%r12),%rax 7: 48 89 03 mov %rax,(%rbx) a: 48 83 e0 fc and $0xfffffffffffffffc,%rax e: 49 89 1c 24 mov %rbx,(%r12) 12: 0f .byte 0xf 13: 84 69 00 test %ch,0x0(%rcx) [ 1196.001744] RIP __rb_erase_color (include/linux/rbtree_augmented.h:107 lib/rbtree.c:229 lib/rbtree.c:367) [ 1196.001744] RSP <ffff8808b25e3d18> [ 1196.001744] CR2: 0000000000000000 [ 1196.001744] ---[ end trace 67e0103d243f3c04 ]--- [ 1196.050031] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 1196.050031] IP: __rb_insert_augmented (lib/rbtree.c:94 lib/rbtree.c:411) [ 1196.050031] PGD a3ea09067 PUD a69b38067 PMD 0 [ 1196.050031] Oops: 0000 [#2] PREEMPT SMP DEBUG_PAGEALLOC [ 1196.050031] Dumping ftrace buffer: [ 1196.050031] (ftrace buffer empty) [ 1196.050031] Modules linked in: [ 1196.050031] CPU: 3 PID: 5688 Comm: trinity-c802 Tainted: G D 3.17.0-rc4-next-20140910-sasha-00042-ga4bad9b-dirty #1140 [ 1196.050031] task: ffff880a508f8000 ti: ffff880a6950c000 task.ti: ffff880a6950c000 [ 1196.050031] RIP: __rb_insert_augmented (lib/rbtree.c:94 lib/rbtree.c:411) [ 1196.050031] RSP: 0018:ffff880a6950fd68 EFLAGS: 00010246 [ 1196.050031] RAX: ffff88091f75a058 RBX: 0000000000000000 RCX: 0000000000000000 [ 1196.050031] RDX: ffffffff912ba700 RSI: ffff8800b4cb3718 RDI: ffff8802d786ca58 [ 1196.050031] RBP: ffff880a6950fd90 R08: ffff8802d786ca00 R09: ffff8800b4cb3718 [ 1196.050031] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8801fd067400 [ 1196.050031] R13: ffff8802d786ca00 R14: ffff8800b4cb3718 R15: 00007f00e44589d0 [ 1196.050031] FS: 00007f00e4458700(0000) GS:ffff88031ac00000(0000) knlGS:0000000000000000 [ 1196.050031] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1196.050031] CR2: 0000000000000008 CR3: 0000000a62597000 CR4: 00000000000006a0 [ 1196.050031] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1196.050031] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000070602 [ 1196.050031] Stack: [ 1196.050031] ffffffff9115499e ffff88028bc7a000 ffff8801fd067400 ffff8802d786ca00 [ 1196.050031] ffff8800b4cb3730 ffff880a6950fda0 ffffffff912babfd ffff880a6950fe70 [ 1196.050031] ffffffff91154a77 ffff8800b4cb36b0 000000003ebe3540 0000000000000000 [ 1196.050031] Call Trace: [ 1196.050031] ? copy_process (kernel/fork.c:409 kernel/fork.c:859 kernel/fork.c:913 kernel/fork.c:1381) [ 1196.050031] vma_interval_tree_insert_after (mm/interval_tree.c:60) [ 1196.050031] copy_process (kernel/fork.c:442 kernel/fork.c:859 kernel/fork.c:913 kernel/fork.c:1381) [ 1196.050031] do_fork (kernel/fork.c:1644) [ 1196.050031] ? context_tracking_user_exit (./arch/x86/include/asm/paravirt.h:809 (discriminator 2) kernel/context_tracking.c:184 (discriminator 2)) [ 1196.050031] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63) [ 1196.050031] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2559 kernel/locking/lockdep.c:2601) [ 1196.050031] ? trace_hardirqs_on (kernel/locking/lockdep.c:2609) [ 1196.050031] SyS_clone (kernel/fork.c:1733) [ 1196.050031] stub_clone (arch/x86/kernel/entry_64.S:637) [ 1196.050031] ? tracesys (arch/x86/kernel/entry_64.S:542) [ 1196.050031] Code: ff ff 0f 1f 00 48 8b 07 48 85 c0 0f 84 a4 01 00 00 55 48 89 e5 41 56 49 89 f6 41 55 41 54 53 48 83 ec 08 48 8b 18 f6 c3 01 75 6b <48> 8b 4b 08 49 89 d8 48 39 c8 0f 84 a5 00 00 00 48 85 c9 74 05 All code ======== 0: ff (bad) 1: ff 0f decl (%rdi) 3: 1f (bad) 4: 00 48 8b add %cl,-0x75(%rax) 7: 07 (bad) 8: 48 85 c0 test %rax,%rax b: 0f 84 a4 01 00 00 je 0x1b5 11: 55 push %rbp 12: 48 89 e5 mov %rsp,%rbp 15: 41 56 push %r14 17: 49 89 f6 mov %rsi,%r14 1a: 41 55 push %r13 1c: 41 54 push %r12 1e: 53 push %rbx 1f: 48 83 ec 08 sub $0x8,%rsp 23: 48 8b 18 mov (%rax),%rbx 26: f6 c3 01 test $0x1,%bl 29: 75 6b jne 0x96 2b:* 48 8b 4b 08 mov 0x8(%rbx),%rcx <-- trapping instruction 2f: 49 89 d8 mov %rbx,%r8 32: 48 39 c8 cmp %rcx,%rax 35: 0f 84 a5 00 00 00 je 0xe0 3b: 48 85 c9 test %rcx,%rcx 3e: 74 05 je 0x45 ... Code starting with the faulting instruction =========================================== 0: 48 8b 4b 08 mov 0x8(%rbx),%rcx 4: 49 89 d8 mov %rbx,%r8 7: 48 39 c8 cmp %rcx,%rax a: 0f 84 a5 00 00 00 je 0xb5 10: 48 85 c9 test %rcx,%rcx 13: 74 05 je 0x1a ... [ 1196.050031] RIP __rb_insert_augmented (lib/rbtree.c:94 lib/rbtree.c:411) [ 1196.050031] RSP <ffff880a6950fd68> [ 1196.050031] CR2: 0000000000000008 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-11 2:43 ` Sasha Levin @ 2014-09-11 11:39 ` Hugh Dickins -1 siblings, 0 replies; 86+ messages in thread From: Hugh Dickins @ 2014-09-11 11:39 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, Mel Gorman, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Wed, 10 Sep 2014, Sasha Levin wrote: > On 09/10/2014 03:36 PM, Hugh Dickins wrote: > > Right, and Sasha reports that that can fire, but he sees the bug > > with this patch in and without that firing. > > I've changed that WARN_ON_ONCE() to a VM_BUG_ON_VMA() to get some useful > VMA information out, and got the following: Well, thanks, but Mel and I have both failed to perceive any actual problem arising from that peculiarity. And Mel's warning, and the 900s in yesterday's dumps, have shown that it is not correlated with the pte_mknuma() bug we are chasing. So there isn't anything that I want to look up in these vmas. Or did you notice something interesting in them? > And on a maybe related note, I've started seeing the following today. It may > be because we fixed mbind() in trinity but it could also be related to The fixed trinity may be counter-productive for now, since we think there is an understandable pte_mknuma() bug coming from that direction, but have not posted a patch for it yet. > this issue (free_pgtables() is in the call chain). If you don't think it has > anything to do with it let me know and I'll start a new thread: > > [ 1195.996803] BUG: unable to handle kernel NULL pointer dereference at (null) > [ 1196.001744] IP: __rb_erase_color (include/linux/rbtree_augmented.h:107 lib/rbtree.c:229 lib/rbtree.c:367) > [ 1196.001744] Call Trace: > [ 1196.001744] vma_interval_tree_remove (mm/interval_tree.c:24) > [ 1196.001744] __remove_shared_vm_struct (mm/mmap.c:232) > [ 1196.001744] unlink_file_vma (mm/mmap.c:246) > [ 1196.001744] free_pgtables (mm/memory.c:547) > [ 1196.001744] exit_mmap (mm/mmap.c:2826) > [ 1196.001744] mmput (kernel/fork.c:654) > [ 1196.001744] do_exit (./arch/x86/include/asm/thread_info.h:168 kernel/exit.c:461 kernel/exit.c:746) I didn't study in any detail, but this one seems much more like the zeroing and vma corruption that you've been seeing in other dumps. Though a single pte_mknuma() crash could presumably be caused by vma corruption (but I think not mere zeroing), the recurrent way in which you hit that pte_mknuma() bug in particular makes it unlikely to be caused by random corruption. You are generating new crashes faster than we can keep up with them. Would this be a suitable point for you to switch over to testing 3.17-rc, to see if that is as unstable for you as -next is? That VM_BUG_ON(!(val & _PAGE_PRESENT)) is not in the 3.17-rc tree, but I think you can "safely" add it to 3.17-rc. Quotes around "safely" meaning that we know that there's a bug to hit, at least in -next, but I don't think it's going to be hit for stupid obvious reasons. And you're using a gcc 5 these days? That's another variable to try removing from the mix, to see if it makes a difference. Hugh ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-11 11:39 ` Hugh Dickins 0 siblings, 0 replies; 86+ messages in thread From: Hugh Dickins @ 2014-09-11 11:39 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, Mel Gorman, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Wed, 10 Sep 2014, Sasha Levin wrote: > On 09/10/2014 03:36 PM, Hugh Dickins wrote: > > Right, and Sasha reports that that can fire, but he sees the bug > > with this patch in and without that firing. > > I've changed that WARN_ON_ONCE() to a VM_BUG_ON_VMA() to get some useful > VMA information out, and got the following: Well, thanks, but Mel and I have both failed to perceive any actual problem arising from that peculiarity. And Mel's warning, and the 900s in yesterday's dumps, have shown that it is not correlated with the pte_mknuma() bug we are chasing. So there isn't anything that I want to look up in these vmas. Or did you notice something interesting in them? > And on a maybe related note, I've started seeing the following today. It may > be because we fixed mbind() in trinity but it could also be related to The fixed trinity may be counter-productive for now, since we think there is an understandable pte_mknuma() bug coming from that direction, but have not posted a patch for it yet. > this issue (free_pgtables() is in the call chain). If you don't think it has > anything to do with it let me know and I'll start a new thread: > > [ 1195.996803] BUG: unable to handle kernel NULL pointer dereference at (null) > [ 1196.001744] IP: __rb_erase_color (include/linux/rbtree_augmented.h:107 lib/rbtree.c:229 lib/rbtree.c:367) > [ 1196.001744] Call Trace: > [ 1196.001744] vma_interval_tree_remove (mm/interval_tree.c:24) > [ 1196.001744] __remove_shared_vm_struct (mm/mmap.c:232) > [ 1196.001744] unlink_file_vma (mm/mmap.c:246) > [ 1196.001744] free_pgtables (mm/memory.c:547) > [ 1196.001744] exit_mmap (mm/mmap.c:2826) > [ 1196.001744] mmput (kernel/fork.c:654) > [ 1196.001744] do_exit (./arch/x86/include/asm/thread_info.h:168 kernel/exit.c:461 kernel/exit.c:746) I didn't study in any detail, but this one seems much more like the zeroing and vma corruption that you've been seeing in other dumps. Though a single pte_mknuma() crash could presumably be caused by vma corruption (but I think not mere zeroing), the recurrent way in which you hit that pte_mknuma() bug in particular makes it unlikely to be caused by random corruption. You are generating new crashes faster than we can keep up with them. Would this be a suitable point for you to switch over to testing 3.17-rc, to see if that is as unstable for you as -next is? That VM_BUG_ON(!(val & _PAGE_PRESENT)) is not in the 3.17-rc tree, but I think you can "safely" add it to 3.17-rc. Quotes around "safely" meaning that we know that there's a bug to hit, at least in -next, but I don't think it's going to be hit for stupid obvious reasons. And you're using a gcc 5 these days? That's another variable to try removing from the mix, to see if it makes a difference. Hugh -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-11 11:39 ` Hugh Dickins @ 2014-09-11 14:22 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-11 14:22 UTC (permalink / raw) To: Hugh Dickins Cc: Mel Gorman, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/11/2014 07:39 AM, Hugh Dickins wrote: > On Wed, 10 Sep 2014, Sasha Levin wrote: >> On 09/10/2014 03:36 PM, Hugh Dickins wrote: >>> Right, and Sasha reports that that can fire, but he sees the bug >>> with this patch in and without that firing. >> >> I've changed that WARN_ON_ONCE() to a VM_BUG_ON_VMA() to get some useful >> VMA information out, and got the following: > > Well, thanks, but Mel and I have both failed to perceive any actual > problem arising from that peculiarity. And Mel's warning, and the 900s > in yesterday's dumps, have shown that it is not correlated with the > pte_mknuma() bug we are chasing. So there isn't anything that I want to > look up in these vmas. Or did you notice something interesting in them? I thought this was a separate issue that would need taking care of as well. >> And on a maybe related note, I've started seeing the following today. It may >> be because we fixed mbind() in trinity but it could also be related to > > The fixed trinity may be counter-productive for now, since we think > there is an understandable pte_mknuma() bug coming from that direction, > but have not posted a patch for it yet. I'm still seeing the bug with fixed trinity, it was a matter of adding more flags to mbind. >> this issue (free_pgtables() is in the call chain). If you don't think it has >> anything to do with it let me know and I'll start a new thread: >> >> [ 1195.996803] BUG: unable to handle kernel NULL pointer dereference at (null) >> [ 1196.001744] IP: __rb_erase_color (include/linux/rbtree_augmented.h:107 lib/rbtree.c:229 lib/rbtree.c:367) >> [ 1196.001744] Call Trace: >> [ 1196.001744] vma_interval_tree_remove (mm/interval_tree.c:24) >> [ 1196.001744] __remove_shared_vm_struct (mm/mmap.c:232) >> [ 1196.001744] unlink_file_vma (mm/mmap.c:246) >> [ 1196.001744] free_pgtables (mm/memory.c:547) >> [ 1196.001744] exit_mmap (mm/mmap.c:2826) >> [ 1196.001744] mmput (kernel/fork.c:654) >> [ 1196.001744] do_exit (./arch/x86/include/asm/thread_info.h:168 kernel/exit.c:461 kernel/exit.c:746) > > I didn't study in any detail, but this one seems much more like the > zeroing and vma corruption that you've been seeing in other dumps. > > Though a single pte_mknuma() crash could presumably be caused by vma > corruption (but I think not mere zeroing), the recurrent way in which > you hit that pte_mknuma() bug in particular makes it unlikely to be > caused by random corruption. > > You are generating new crashes faster than we can keep up with them. > Would this be a suitable point for you to switch over to testing > 3.17-rc, to see if that is as unstable for you as -next is? > > That VM_BUG_ON(!(val & _PAGE_PRESENT)) is not in the 3.17-rc tree, > but I think you can "safely" add it to 3.17-rc. Quotes around > "safely" meaning that we know that there's a bug to hit, at least > in -next, but I don't think it's going to be hit for stupid obvious > reasons. I'll try it, usually I just hit a bunch of issues that were already fixed in -next, which is why I try sticking to one tree. > And you're using a gcc 5 these days? That's another variable to > try removing from the mix, to see if it makes a difference. I'm seeing the BUG getting hit with 4.7.2, so I don't think it's compiler dependant. I'll try reproducing everything I reported yesterday with 4.7.2 just in case, but I don't think that this is the issue. Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-11 14:22 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-11 14:22 UTC (permalink / raw) To: Hugh Dickins Cc: Mel Gorman, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/11/2014 07:39 AM, Hugh Dickins wrote: > On Wed, 10 Sep 2014, Sasha Levin wrote: >> On 09/10/2014 03:36 PM, Hugh Dickins wrote: >>> Right, and Sasha reports that that can fire, but he sees the bug >>> with this patch in and without that firing. >> >> I've changed that WARN_ON_ONCE() to a VM_BUG_ON_VMA() to get some useful >> VMA information out, and got the following: > > Well, thanks, but Mel and I have both failed to perceive any actual > problem arising from that peculiarity. And Mel's warning, and the 900s > in yesterday's dumps, have shown that it is not correlated with the > pte_mknuma() bug we are chasing. So there isn't anything that I want to > look up in these vmas. Or did you notice something interesting in them? I thought this was a separate issue that would need taking care of as well. >> And on a maybe related note, I've started seeing the following today. It may >> be because we fixed mbind() in trinity but it could also be related to > > The fixed trinity may be counter-productive for now, since we think > there is an understandable pte_mknuma() bug coming from that direction, > but have not posted a patch for it yet. I'm still seeing the bug with fixed trinity, it was a matter of adding more flags to mbind. >> this issue (free_pgtables() is in the call chain). If you don't think it has >> anything to do with it let me know and I'll start a new thread: >> >> [ 1195.996803] BUG: unable to handle kernel NULL pointer dereference at (null) >> [ 1196.001744] IP: __rb_erase_color (include/linux/rbtree_augmented.h:107 lib/rbtree.c:229 lib/rbtree.c:367) >> [ 1196.001744] Call Trace: >> [ 1196.001744] vma_interval_tree_remove (mm/interval_tree.c:24) >> [ 1196.001744] __remove_shared_vm_struct (mm/mmap.c:232) >> [ 1196.001744] unlink_file_vma (mm/mmap.c:246) >> [ 1196.001744] free_pgtables (mm/memory.c:547) >> [ 1196.001744] exit_mmap (mm/mmap.c:2826) >> [ 1196.001744] mmput (kernel/fork.c:654) >> [ 1196.001744] do_exit (./arch/x86/include/asm/thread_info.h:168 kernel/exit.c:461 kernel/exit.c:746) > > I didn't study in any detail, but this one seems much more like the > zeroing and vma corruption that you've been seeing in other dumps. > > Though a single pte_mknuma() crash could presumably be caused by vma > corruption (but I think not mere zeroing), the recurrent way in which > you hit that pte_mknuma() bug in particular makes it unlikely to be > caused by random corruption. > > You are generating new crashes faster than we can keep up with them. > Would this be a suitable point for you to switch over to testing > 3.17-rc, to see if that is as unstable for you as -next is? > > That VM_BUG_ON(!(val & _PAGE_PRESENT)) is not in the 3.17-rc tree, > but I think you can "safely" add it to 3.17-rc. Quotes around > "safely" meaning that we know that there's a bug to hit, at least > in -next, but I don't think it's going to be hit for stupid obvious > reasons. I'll try it, usually I just hit a bunch of issues that were already fixed in -next, which is why I try sticking to one tree. > And you're using a gcc 5 these days? That's another variable to > try removing from the mix, to see if it makes a difference. I'm seeing the BUG getting hit with 4.7.2, so I don't think it's compiler dependant. I'll try reproducing everything I reported yesterday with 4.7.2 just in case, but I don't think that this is the issue. 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-11 14:22 ` Sasha Levin @ 2014-09-11 14:33 ` Dave Jones -1 siblings, 0 replies; 86+ messages in thread From: Dave Jones @ 2014-09-11 14:33 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, Mel Gorman, linux-mm, Andrew Morton, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Thu, Sep 11, 2014 at 10:22:42AM -0400, Sasha Levin wrote: > > The fixed trinity may be counter-productive for now, since we think > > there is an understandable pte_mknuma() bug coming from that direction, > > but have not posted a patch for it yet. > > I'm still seeing the bug with fixed trinity, it was a matter of adding more flags > to mbind. What did I miss ? Anything not in the MPOL_MF_VALID mask should be -EINVAL Dave ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-11 14:33 ` Dave Jones 0 siblings, 0 replies; 86+ messages in thread From: Dave Jones @ 2014-09-11 14:33 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, Mel Gorman, linux-mm, Andrew Morton, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Thu, Sep 11, 2014 at 10:22:42AM -0400, Sasha Levin wrote: > > The fixed trinity may be counter-productive for now, since we think > > there is an understandable pte_mknuma() bug coming from that direction, > > but have not posted a patch for it yet. > > I'm still seeing the bug with fixed trinity, it was a matter of adding more flags > to mbind. What did I miss ? Anything not in the MPOL_MF_VALID mask should be -EINVAL Dave -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-11 11:39 ` Hugh Dickins @ 2014-09-11 16:28 ` Mel Gorman -1 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-09-11 16:28 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Thu, Sep 11, 2014 at 04:39:39AM -0700, Hugh Dickins wrote: > On Wed, 10 Sep 2014, Sasha Levin wrote: > > On 09/10/2014 03:36 PM, Hugh Dickins wrote: > > > Right, and Sasha reports that that can fire, but he sees the bug > > > with this patch in and without that firing. > > > > I've changed that WARN_ON_ONCE() to a VM_BUG_ON_VMA() to get some useful > > VMA information out, and got the following: > > Well, thanks, but Mel and I have both failed to perceive any actual > problem arising from that peculiarity. And Mel's warning, and the 900s > in yesterday's dumps, have shown that it is not correlated with the > pte_mknuma() bug we are chasing. So there isn't anything that I want to > look up in these vmas. Or did you notice something interesting in them? > > > And on a maybe related note, I've started seeing the following today. It may > > be because we fixed mbind() in trinity but it could also be related to > > The fixed trinity may be counter-productive for now, since we think > there is an understandable pte_mknuma() bug coming from that direction, > but have not posted a patch for it yet. > > > this issue (free_pgtables() is in the call chain). If you don't think it has > > anything to do with it let me know and I'll start a new thread: > > > > [ 1195.996803] BUG: unable to handle kernel NULL pointer dereference at (null) > > [ 1196.001744] IP: __rb_erase_color (include/linux/rbtree_augmented.h:107 lib/rbtree.c:229 lib/rbtree.c:367) > > [ 1196.001744] Call Trace: > > [ 1196.001744] vma_interval_tree_remove (mm/interval_tree.c:24) > > [ 1196.001744] __remove_shared_vm_struct (mm/mmap.c:232) > > [ 1196.001744] unlink_file_vma (mm/mmap.c:246) > > [ 1196.001744] free_pgtables (mm/memory.c:547) > > [ 1196.001744] exit_mmap (mm/mmap.c:2826) > > [ 1196.001744] mmput (kernel/fork.c:654) > > [ 1196.001744] do_exit (./arch/x86/include/asm/thread_info.h:168 kernel/exit.c:461 kernel/exit.c:746) > > I didn't study in any detail, but this one seems much more like the > zeroing and vma corruption that you've been seeing in other dumps. > I didn't look through the dumps closely today because I spent the time putting together a KVM setup similar to Sasha's (many cpus, fake NUMA, etc) so I could run trinity in it in another attempt to reproduce this. I did not encounter the same VM_BUG_ON unfortunately. However, trinity itself crashed after 2.5 hours complaining [watchdog] pid 32188 has disappeared. Reaping. [watchdog] pid 32024 has disappeared. Reaping. [watchdog] pid 32300 has disappeared. Reaping. [watchdog] Sanity check failed! Found pid 0 at pidslot 35! This did not happen when running on bare metal. This error makes me wonder if it is evidence that there is zeroing corruption occuring when running inside KVM. Another possibility is that it's somehow related to fake NUMA although it's hard to see how. It's still possible the bug is with the page table handling and KVM affects timing enough to cause problems so I'm not ruling that out. > Though a single pte_mknuma() crash could presumably be caused by vma > corruption (but I think not mere zeroing), the recurrent way in which > you hit that pte_mknuma() bug in particular makes it unlikely to be > caused by random corruption. > > You are generating new crashes faster than we can keep up with them. > Would this be a suitable point for you to switch over to testing > 3.17-rc, to see if that is as unstable for you as -next is? > > That VM_BUG_ON(!(val & _PAGE_PRESENT)) is not in the 3.17-rc tree, > but I think you can "safely" add it to 3.17-rc. Quotes around > "safely" meaning that we know that there's a bug to hit, at least > in -next, but I don't think it's going to be hit for stupid obvious > reasons. > Agreed. If 3.17-rc4 looks stable with the VM_BUG_ON then it would be really nice if you could bisect 3.17-rc4 to linux-next carrying the VM_BUG_ON(!(val & _PAGE_PRESENT)) check at each bisection point. I'm not 100% sure if I'm seeing the same corruption as you or some other issue and do not want to conflate numerous different problems into one. I know this is a pain in the ass but if 3.17-rc4 looks stable then a bisection might be faster overall than my constant head scratching :( -- Mel Gorman SUSE Labs ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-11 16:28 ` Mel Gorman 0 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-09-11 16:28 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Thu, Sep 11, 2014 at 04:39:39AM -0700, Hugh Dickins wrote: > On Wed, 10 Sep 2014, Sasha Levin wrote: > > On 09/10/2014 03:36 PM, Hugh Dickins wrote: > > > Right, and Sasha reports that that can fire, but he sees the bug > > > with this patch in and without that firing. > > > > I've changed that WARN_ON_ONCE() to a VM_BUG_ON_VMA() to get some useful > > VMA information out, and got the following: > > Well, thanks, but Mel and I have both failed to perceive any actual > problem arising from that peculiarity. And Mel's warning, and the 900s > in yesterday's dumps, have shown that it is not correlated with the > pte_mknuma() bug we are chasing. So there isn't anything that I want to > look up in these vmas. Or did you notice something interesting in them? > > > And on a maybe related note, I've started seeing the following today. It may > > be because we fixed mbind() in trinity but it could also be related to > > The fixed trinity may be counter-productive for now, since we think > there is an understandable pte_mknuma() bug coming from that direction, > but have not posted a patch for it yet. > > > this issue (free_pgtables() is in the call chain). If you don't think it has > > anything to do with it let me know and I'll start a new thread: > > > > [ 1195.996803] BUG: unable to handle kernel NULL pointer dereference at (null) > > [ 1196.001744] IP: __rb_erase_color (include/linux/rbtree_augmented.h:107 lib/rbtree.c:229 lib/rbtree.c:367) > > [ 1196.001744] Call Trace: > > [ 1196.001744] vma_interval_tree_remove (mm/interval_tree.c:24) > > [ 1196.001744] __remove_shared_vm_struct (mm/mmap.c:232) > > [ 1196.001744] unlink_file_vma (mm/mmap.c:246) > > [ 1196.001744] free_pgtables (mm/memory.c:547) > > [ 1196.001744] exit_mmap (mm/mmap.c:2826) > > [ 1196.001744] mmput (kernel/fork.c:654) > > [ 1196.001744] do_exit (./arch/x86/include/asm/thread_info.h:168 kernel/exit.c:461 kernel/exit.c:746) > > I didn't study in any detail, but this one seems much more like the > zeroing and vma corruption that you've been seeing in other dumps. > I didn't look through the dumps closely today because I spent the time putting together a KVM setup similar to Sasha's (many cpus, fake NUMA, etc) so I could run trinity in it in another attempt to reproduce this. I did not encounter the same VM_BUG_ON unfortunately. However, trinity itself crashed after 2.5 hours complaining [watchdog] pid 32188 has disappeared. Reaping. [watchdog] pid 32024 has disappeared. Reaping. [watchdog] pid 32300 has disappeared. Reaping. [watchdog] Sanity check failed! Found pid 0 at pidslot 35! This did not happen when running on bare metal. This error makes me wonder if it is evidence that there is zeroing corruption occuring when running inside KVM. Another possibility is that it's somehow related to fake NUMA although it's hard to see how. It's still possible the bug is with the page table handling and KVM affects timing enough to cause problems so I'm not ruling that out. > Though a single pte_mknuma() crash could presumably be caused by vma > corruption (but I think not mere zeroing), the recurrent way in which > you hit that pte_mknuma() bug in particular makes it unlikely to be > caused by random corruption. > > You are generating new crashes faster than we can keep up with them. > Would this be a suitable point for you to switch over to testing > 3.17-rc, to see if that is as unstable for you as -next is? > > That VM_BUG_ON(!(val & _PAGE_PRESENT)) is not in the 3.17-rc tree, > but I think you can "safely" add it to 3.17-rc. Quotes around > "safely" meaning that we know that there's a bug to hit, at least > in -next, but I don't think it's going to be hit for stupid obvious > reasons. > Agreed. If 3.17-rc4 looks stable with the VM_BUG_ON then it would be really nice if you could bisect 3.17-rc4 to linux-next carrying the VM_BUG_ON(!(val & _PAGE_PRESENT)) check at each bisection point. I'm not 100% sure if I'm seeing the same corruption as you or some other issue and do not want to conflate numerous different problems into one. I know this is a pain in the ass but if 3.17-rc4 looks stable then a bisection might be faster overall than my constant head scratching :( -- Mel Gorman SUSE Labs -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-11 16:28 ` Mel Gorman @ 2014-09-11 22:38 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-11 22:38 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/11/2014 12:28 PM, Mel Gorman wrote: > Agreed. If 3.17-rc4 looks stable with the VM_BUG_ON then it would be > really nice if you could bisect 3.17-rc4 to linux-next carrying the > VM_BUG_ON(!(val & _PAGE_PRESENT)) check at each bisection point. I'm not > 100% sure if I'm seeing the same corruption as you or some other issue and > do not want to conflate numerous different problems into one. I know this > is a pain in the ass but if 3.17-rc4 looks stable then a bisection might > be faster overall than my constant head scratching :( The good news are that 3.17-rc4 seems to be stable. I'll start the bisection, which I suspect would take several days. I'll update when I run into something. Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-11 22:38 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-11 22:38 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/11/2014 12:28 PM, Mel Gorman wrote: > Agreed. If 3.17-rc4 looks stable with the VM_BUG_ON then it would be > really nice if you could bisect 3.17-rc4 to linux-next carrying the > VM_BUG_ON(!(val & _PAGE_PRESENT)) check at each bisection point. I'm not > 100% sure if I'm seeing the same corruption as you or some other issue and > do not want to conflate numerous different problems into one. I know this > is a pain in the ass but if 3.17-rc4 looks stable then a bisection might > be faster overall than my constant head scratching :( The good news are that 3.17-rc4 seems to be stable. I'll start the bisection, which I suspect would take several days. I'll update when I run into something. 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-11 22:38 ` Sasha Levin @ 2014-09-17 21:37 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-17 21:37 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/11/2014 06:38 PM, Sasha Levin wrote: > On 09/11/2014 12:28 PM, Mel Gorman wrote: >> > Agreed. If 3.17-rc4 looks stable with the VM_BUG_ON then it would be >> > really nice if you could bisect 3.17-rc4 to linux-next carrying the >> > VM_BUG_ON(!(val & _PAGE_PRESENT)) check at each bisection point. I'm not >> > 100% sure if I'm seeing the same corruption as you or some other issue and >> > do not want to conflate numerous different problems into one. I know this >> > is a pain in the ass but if 3.17-rc4 looks stable then a bisection might >> > be faster overall than my constant head scratching :( > The good news are that 3.17-rc4 seems to be stable. I'll start the bisection, > which I suspect would take several days. I'll update when I run into something. I might need a bit of a help here. The bisection is going sideways because I can't reliably reproduce the issue. We don't know what's causing this issue, but we know what the symptoms are. Is there a VM_BUG_ON we could add somewhere so that it would be more likely to trigger? Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-17 21:37 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-17 21:37 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/11/2014 06:38 PM, Sasha Levin wrote: > On 09/11/2014 12:28 PM, Mel Gorman wrote: >> > Agreed. If 3.17-rc4 looks stable with the VM_BUG_ON then it would be >> > really nice if you could bisect 3.17-rc4 to linux-next carrying the >> > VM_BUG_ON(!(val & _PAGE_PRESENT)) check at each bisection point. I'm not >> > 100% sure if I'm seeing the same corruption as you or some other issue and >> > do not want to conflate numerous different problems into one. I know this >> > is a pain in the ass but if 3.17-rc4 looks stable then a bisection might >> > be faster overall than my constant head scratching :( > The good news are that 3.17-rc4 seems to be stable. I'll start the bisection, > which I suspect would take several days. I'll update when I run into something. I might need a bit of a help here. The bisection is going sideways because I can't reliably reproduce the issue. We don't know what's causing this issue, but we know what the symptoms are. Is there a VM_BUG_ON we could add somewhere so that it would be more likely to trigger? 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-10 2:45 ` Hugh Dickins @ 2014-09-10 13:12 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-10 13:12 UTC (permalink / raw) To: Hugh Dickins Cc: Mel Gorman, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/09/2014 10:45 PM, Hugh Dickins wrote: > Sasha, you say you're getting plenty of these now, but I've only seen > the dump for one of them, on Aug26: please post a few more dumps, so > that we can look for commonality. I wasn't saving older logs for this issue so I only have 2 traces from tonight. If that's not enough please let me know and I'll try to add a few more. [ 1125.600123] kernel BUG at include/asm-generic/pgtable.h:724! [ 1125.600123] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 1125.600123] Dumping ftrace buffer: [ 1125.600123] (ftrace buffer empty) [ 1125.600123] Modules linked in: [ 1125.600123] CPU: 16 PID: 11903 Comm: trinity-c517 Not tainted 3.17.0-rc4-next-20140909-sasha-00032-gc16d47b #1135 [ 1125.600123] task: ffff880661730000 ti: ffff880582c20000 task.ti: ffff880582c20000 [ 1125.600123] RIP: 0010:[<ffffffffa32e500a>] [<ffffffffa32e500a>] change_pte_range+0x4ea/0x4f0 [ 1125.600123] RSP: 0018:ffff880582c23d68 EFLAGS: 00010246 [ 1125.600123] RAX: 0000000936d9a900 RBX: 00007ffdb17c8000 RCX: 0000000000000100 [ 1125.600123] RDX: 0000000936d9a900 RSI: 00007ffdb17c8000 RDI: 0000000936d9a900 [ 1125.600123] RBP: ffff880582c23dc8 R08: ffff8802a8f2d400 R09: 0000000000b56000 [ 1125.600123] R10: 0000000000020201 R11: 0000000000000008 R12: ffff88004dd6ee40 [ 1125.600123] R13: 8000000000000025 R14: 00007ffdb1800000 R15: ffffc00000000fff [ 1125.600123] FS: 00007ffdb6382700(0000) GS:ffff880278200000(0000) knlGS:0000000000000000 [ 1125.600123] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1125.600123] CR2: 00007ffdb617e60c CR3: 000000050ff12000 CR4: 00000000000006a0 [ 1125.600123] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1125.600123] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 [ 1125.600123] Stack: [ 1125.600123] 0000000000000001 0000000936d9a900 0000000000000046 ffff8804bd549f40 [ 1125.600123] 000000001f989000 ffff8802a8f2d400 ffff88051f989000 00007f9f40604cfdb1ac8000 [ 1125.600123] ffff88032fcc3c58 00007ffdb16df000 00007ffdb16df000 00007ffdb1800000 [ 1125.600123] Call Trace: [ 1125.600123] [<ffffffffa32e52c4>] change_protection+0x2b4/0x4e0 [ 1125.600123] [<ffffffffa32fefdb>] change_prot_numa+0x1b/0x40 [ 1125.600123] [<ffffffffa31add86>] task_numa_work+0x1f6/0x330 [ 1125.600123] [<ffffffffa3193d84>] task_work_run+0xc4/0xf0 [ 1125.600123] [<ffffffffa3071477>] do_notify_resume+0x97/0xb0 [ 1125.600123] [<ffffffffa650daea>] int_signal+0x12/0x17 [ 1125.600123] Code: 66 90 48 8b 7d b8 e8 f6 75 22 03 48 8b 45 b0 e9 6f ff ff ff 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b <0f> 0b 0f 0b 0f 0b 66 66 66 66 90 55 48 89 e5 41 57 49 89 d7 41 [ 1125.600123] RIP [<ffffffffa32e500a>] change_pte_range+0x4ea/0x4f0 [ 1125.600123] RSP <ffff880582c23d68> [ 3131.084176] kernel BUG at include/asm-generic/pgtable.h:724! [ 3131.087358] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 3131.090143] Dumping ftrace buffer: [ 3131.090143] (ftrace buffer empty) [ 3131.090143] Modules linked in: [ 3131.090143] CPU: 8 PID: 20595 Comm: trinity-c34 Not tainted 3.17.0-rc4-next-20140909-sasha-00032-gc16d47b #1135 [ 3131.090143] task: ffff8801ded60000 ti: ffff8803204ec000 task.ti: ffff8803204ec000 [ 3131.090143] RIP: 0010:[<ffffffffa72e500a>] [<ffffffffa72e500a>] change_pte_range+0x4ea/0x4f0 [ 3131.090143] RSP: 0000:ffff8803204efd68 EFLAGS: 00010246 [ 3131.090143] RAX: 0000000971bba900 RBX: 00007ffda1d4d000 RCX: 0000000000000100 [ 3131.090143] RDX: 0000000971bba900 RSI: 00007ffda1d4d000 RDI: 0000000971bba900 [ 3131.120281] RBP: ffff8803204efdc8 R08: ffff88026bed8800 R09: 0000000000b48000 [ 3131.120281] R10: 0000000000076501 R11: 0000000000000008 R12: ffff8801ca071a68 [ 3131.120281] R13: 8000000000000025 R14: 00007ffda1dbf000 R15: ffffc00000000fff [ 3131.120281] FS: 00007ffda5cd4700(0000) GS:ffff880277e00000(0000) knlGS:0000000000000000 [ 3131.120281] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3131.120281] CR2: 00000000025d6000 CR3: 00000004bcde2000 CR4: 00000000000006a0 [ 3131.120281] Stack: [ 3131.120281] 0000000000000001 0000000971bba900 000000000000005c ffff8800661a7b60 [ 3131.120281] 00000000f4953000 ffff88026bed8800 ffff8801f4953000 00007ffda1dbf000 [ 3131.120281] ffff8802b3319870 00007ffda1c1b000 00007ffda1c1b000 00007ffda1dbf000 [ 3131.120281] Call Trace: [ 3131.120281] [<ffffffffa72e52c4>] change_protection+0x2b4/0x4e0 [ 3131.120281] [<ffffffffa72fefdb>] change_prot_numa+0x1b/0x40 [ 3131.120281] [<ffffffffa71add86>] task_numa_work+0x1f6/0x330 [ 3131.120281] [<ffffffffa7193d84>] task_work_run+0xc4/0xf0 [ 3131.120281] [<ffffffffa7071477>] do_notify_resume+0x97/0xb0 [ 3131.120281] [<ffffffffaa50e6ae>] retint_signal+0x4d/0x9f [ 3131.120281] Code: 66 90 48 8b 7d b8 e8 f6 75 22 03 48 8b 45 b0 e9 6f ff ff ff 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b <0f> 0b 0f 0b 0f 0b 66 66 66 66 90 55 48 89 e5 41 57 49 89 d7 41 [ 3131.120281] RIP [<ffffffffa72e500a>] change_pte_range+0x4ea/0x4f0 [ 3131.120281] RSP <ffff8803204efd68> > And please attach a disassembly of change_protection_range() (noting > which of the dumps it corresponds to, in case it has changed around): > "Code" just shows a cluster of ud2s for the unlikely bugs at end of the > function, we cannot tell at all what should be in the registers by then. change_protection_range() got inlined into change_protection(), it applies to both traces above: 00000000000004f0 <change_protection>: 4f0: e8 00 00 00 00 callq 4f5 <change_protection+0x5> 4f1: R_X86_64_PC32 __fentry__-0x4 4f5: 55 push %rbp 4f6: 48 89 e5 mov %rsp,%rbp 4f9: 41 57 push %r15 4fb: 49 89 d7 mov %rdx,%r15 4fe: 41 56 push %r14 500: 41 55 push %r13 502: 41 54 push %r12 504: 53 push %rbx 505: 48 81 ec 98 00 00 00 sub $0x98,%rsp 50c: 48 89 7d c8 mov %rdi,-0x38(%rbp) 510: 48 89 75 c0 mov %rsi,-0x40(%rbp) 514: 48 89 4d b8 mov %rcx,-0x48(%rbp) 518: 44 89 45 98 mov %r8d,-0x68(%rbp) 51c: 44 89 4d 9c mov %r9d,-0x64(%rbp) 520: f6 47 52 40 testb $0x40,0x52(%rdi) 524: 0f 85 96 03 00 00 jne 8c0 <change_protection+0x3d0> 52a: 48 8b 45 c8 mov -0x38(%rbp),%rax 52e: 48 8b 40 40 mov 0x40(%rax),%rax 532: 48 89 45 80 mov %rax,-0x80(%rbp) 536: 48 39 55 c0 cmp %rdx,-0x40(%rbp) 53a: 0f 83 40 04 00 00 jae 980 <change_protection+0x490> 540: 4c 8b 5d c0 mov -0x40(%rbp),%r11 544: 48 8b 4d 80 mov -0x80(%rbp),%rcx 548: 4c 89 d8 mov %r11,%rax 54b: 48 c1 e8 24 shr $0x24,%rax 54f: c6 81 dc 08 00 00 01 movb $0x1,0x8dc(%rcx) 556: 25 f8 0f 00 00 and $0xff8,%eax 55b: 48 03 41 40 add 0x40(%rcx),%rax 55f: 48 8d 52 ff lea -0x1(%rdx),%rdx 563: 4c 89 7d d0 mov %r15,-0x30(%rbp) 567: 49 89 c7 mov %rax,%r15 56a: 48 89 55 b0 mov %rdx,-0x50(%rbp) 56e: 48 c7 45 a8 00 00 00 movq $0x0,-0x58(%rbp) 575: 00 576: 48 b8 00 00 00 00 80 movabs $0x8000000000,%rax 57d: 00 00 00 580: 49 8b 3f mov (%r15),%rdi 583: 49 bd 00 00 00 00 80 movabs $0xffffff8000000000,%r13 58a: ff ff ff 58d: 4c 01 d8 add %r11,%rax 590: 49 21 c5 and %rax,%r13 593: 49 8d 45 ff lea -0x1(%r13),%rax 597: 48 3b 45 b0 cmp -0x50(%rbp),%rax 59b: 4c 0f 43 6d d0 cmovae -0x30(%rbp),%r13 5a0: 48 85 ff test %rdi,%rdi 5a3: 0f 84 2f 02 00 00 je 7d8 <change_protection+0x2e8> 5a9: 48 b8 fb 0f 00 00 00 movabs $0xffffc00000000ffb,%rax 5b0: c0 ff ff 5b3: 48 21 f8 and %rdi,%rax 5b6: 48 83 f8 63 cmp $0x63,%rax 5ba: 0f 85 98 03 00 00 jne 958 <change_protection+0x468> 5c0: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 5c8 <change_protection+0xd8> 5c7: 00 5c3: R_X86_64_PC32 pv_mmu_ops+0xf3 5c8: 0f 84 d2 03 00 00 je 9a0 <change_protection+0x4b0> 5ce: ff 14 25 00 00 00 00 callq *0x0 5d1: R_X86_64_32S pv_mmu_ops+0xf8 5d5: 4c 89 df mov %r11,%rdi 5d8: 4d 89 ea mov %r13,%r10 5db: 4c 89 bd 60 ff ff ff mov %r15,-0xa0(%rbp) 5e2: 48 ba 00 f0 ff ff ff movabs $0x3ffffffff000,%rdx 5e9: 3f 00 00 5ec: 48 c1 ef 1b shr $0x1b,%rdi 5f0: 48 21 d0 and %rdx,%rax 5f3: 48 be 00 00 00 00 00 movabs $0xffff880000000000,%rsi 5fa: 88 ff ff 5fd: 48 c7 85 68 ff ff ff movq $0x0,-0x98(%rbp) 604: 00 00 00 00 608: 81 e7 f8 0f 00 00 and $0xff8,%edi 60e: 48 89 95 70 ff ff ff mov %rdx,-0x90(%rbp) 615: 48 01 f7 add %rsi,%rdi 618: 4c 8d 34 07 lea (%rdi,%rax,1),%r14 61c: 49 8d 45 ff lea -0x1(%r13),%rax 620: 4d 89 f5 mov %r14,%r13 623: 4d 89 de mov %r11,%r14 626: 48 89 45 a0 mov %rax,-0x60(%rbp) 62a: 49 8d 9e 00 00 00 40 lea 0x40000000(%r14),%rbx 631: 49 8b 7d 00 mov 0x0(%r13),%rdi 635: 48 81 e3 00 00 00 c0 and $0xffffffffc0000000,%rbx 63c: 48 8d 43 ff lea -0x1(%rbx),%rax 640: 48 3b 45 a0 cmp -0x60(%rbp),%rax 644: 49 0f 43 da cmovae %r10,%rbx 648: 48 85 ff test %rdi,%rdi 64b: 0f 84 ff 01 00 00 je 850 <change_protection+0x360> 651: 48 b8 98 0f 00 00 00 movabs $0xffffc00000000f98,%rax 658: c0 ff ff 65b: 48 85 c7 test %rax,%rdi 65e: 0f 85 04 03 00 00 jne 968 <change_protection+0x478> 664: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 66c <change_protection+0x17c> 66b: 00 667: R_X86_64_PC32 pv_mmu_ops+0x11b 66c: 0f 84 4e 03 00 00 je 9c0 <change_protection+0x4d0> 672: 48 8b 45 c8 mov -0x38(%rbp),%rax 676: 48 8b 40 40 mov 0x40(%rax),%rax 67a: 48 89 85 78 ff ff ff mov %rax,-0x88(%rbp) 681: ff 14 25 00 00 00 00 callq *0x0 684: R_X86_64_32S pv_mmu_ops+0x120 688: 48 23 85 70 ff ff ff and -0x90(%rbp),%rax 68f: 4d 89 f4 mov %r14,%r12 692: 45 31 db xor %r11d,%r11d 695: 4c 89 ad 48 ff ff ff mov %r13,-0xb8(%rbp) 69c: 49 c1 ec 12 shr $0x12,%r12 6a0: 48 c7 45 88 00 00 00 movq $0x0,-0x78(%rbp) 6a7: 00 6a8: 4d 89 dd mov %r11,%r13 6ab: 41 81 e4 f8 0f 00 00 and $0xff8,%r12d 6b2: 4c 89 95 50 ff ff ff mov %r10,-0xb0(%rbp) 6b9: 48 ba 00 00 00 00 00 movabs $0xffff880000000000,%rdx 6c0: 88 ff ff 6c3: 48 c7 85 58 ff ff ff movq $0x0,-0xa8(%rbp) 6ca: 00 00 00 00 6ce: 49 01 d4 add %rdx,%r12 6d1: 49 01 c4 add %rax,%r12 6d4: 48 8d 43 ff lea -0x1(%rbx),%rax 6d8: 48 89 45 90 mov %rax,-0x70(%rbp) 6dc: 4d 8d be 00 00 20 00 lea 0x200000(%r14),%r15 6e3: 49 8b 3c 24 mov (%r12),%rdi 6e7: 49 81 e7 00 00 e0 ff and $0xffffffffffe00000,%r15 6ee: 49 8d 47 ff lea -0x1(%r15),%rax 6f2: 48 3b 45 90 cmp -0x70(%rbp),%rax 6f6: 4c 0f 43 fb cmovae %rbx,%r15 6fa: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 702 <change_protection+0x212> 701: 00 6fd: R_X86_64_PC32 pv_mmu_ops+0x10b 702: 0f 84 60 01 00 00 je 868 <change_protection+0x378> 708: ff 14 25 00 00 00 00 callq *0x0 70b: R_X86_64_32S pv_mmu_ops+0x110 70f: a8 80 test $0x80,%al 711: 0f 84 59 01 00 00 je 870 <change_protection+0x380> 717: 4d 85 ed test %r13,%r13 71a: 75 18 jne 734 <change_protection+0x244> 71c: 48 8b 85 78 ff ff ff mov -0x88(%rbp),%rax 723: 4d 89 f5 mov %r14,%r13 726: 48 83 b8 c0 04 00 00 cmpq $0x0,0x4c0(%rax) 72d: 00 72e: 0f 85 54 02 00 00 jne 988 <change_protection+0x498> 734: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 73c <change_protection+0x24c> 73b: 00 737: R_X86_64_PC32 pv_mmu_ops+0x10b 73c: 49 8b 3c 24 mov (%r12),%rdi 740: 0f 84 22 01 00 00 je 868 <change_protection+0x378> 746: ff 14 25 00 00 00 00 callq *0x0 749: R_X86_64_32S pv_mmu_ops+0x110 74d: a8 80 test $0x80,%al 74f: 74 33 je 784 <change_protection+0x294> 751: 4c 89 f8 mov %r15,%rax 754: 4c 29 f0 sub %r14,%rax 757: 48 3d 00 00 20 00 cmp $0x200000,%rax 75d: 0f 84 7d 01 00 00 je 8e0 <change_protection+0x3f0> 763: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 76b <change_protection+0x27b> 76a: 00 766: R_X86_64_PC32 pv_mmu_ops+0x10b 76b: 49 8b 3c 24 mov (%r12),%rdi 76f: 0f 84 f3 00 00 00 je 868 <change_protection+0x378> 775: ff 14 25 00 00 00 00 callq *0x0 778: R_X86_64_32S pv_mmu_ops+0x110 77c: a8 80 test $0x80,%al 77e: 0f 85 24 02 00 00 jne 9a8 <change_protection+0x4b8> 784: 8b 45 9c mov -0x64(%rbp),%eax 787: 4c 89 f9 mov %r15,%rcx 78a: 4c 89 f2 mov %r14,%rdx 78d: 4c 89 e6 mov %r12,%rsi 790: 44 8b 4d 98 mov -0x68(%rbp),%r9d 794: 4c 8b 45 b8 mov -0x48(%rbp),%r8 798: 48 8b 7d c8 mov -0x38(%rbp),%rdi 79c: 89 04 24 mov %eax,(%rsp) 79f: e8 5c f8 ff ff callq 0 <change_pte_range> 7a4: 48 01 45 88 add %rax,-0x78(%rbp) 7a8: 49 83 c4 08 add $0x8,%r12 7ac: 4c 39 fb cmp %r15,%rbx 7af: 74 3f je 7f0 <change_protection+0x300> 7b1: 4d 89 fe mov %r15,%r14 7b4: e9 23 ff ff ff jmpq 6dc <change_protection+0x1ec> 7b9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 7c0: 48 8b b5 68 ff ff ff mov -0x98(%rbp),%rsi 7c7: 4d 89 d5 mov %r10,%r13 7ca: 4c 8b bd 60 ff ff ff mov -0xa0(%rbp),%r15 7d1: 48 01 75 a8 add %rsi,-0x58(%rbp) 7d5: 0f 1f 00 nopl (%rax) 7d8: 49 83 c7 08 add $0x8,%r15 7dc: 4c 39 6d d0 cmp %r13,-0x30(%rbp) 7e0: 0f 84 3a 01 00 00 je 920 <change_protection+0x430> 7e6: 4d 89 eb mov %r13,%r11 7e9: e9 88 fd ff ff jmpq 576 <change_protection+0x86> 7ee: 66 90 xchg %ax,%ax 7f0: 4d 89 eb mov %r13,%r11 7f3: 4c 8b 95 50 ff ff ff mov -0xb0(%rbp),%r10 7fa: 4c 8b ad 48 ff ff ff mov -0xb8(%rbp),%r13 801: 4d 85 db test %r11,%r11 804: 74 2a je 830 <change_protection+0x340> 806: 48 8b 85 78 ff ff ff mov -0x88(%rbp),%rax 80d: 48 83 b8 c0 04 00 00 cmpq $0x0,0x4c0(%rax) 814: 00 815: 74 19 je 830 <change_protection+0x340> 817: 48 89 da mov %rbx,%rdx 81a: 4c 89 de mov %r11,%rsi 81d: 48 89 c7 mov %rax,%rdi 820: 4c 89 55 90 mov %r10,-0x70(%rbp) 824: e8 00 00 00 00 callq 829 <change_protection+0x339> 825: R_X86_64_PC32 __mmu_notifier_invalidate_range_end-0x4 829: 4c 8b 55 90 mov -0x70(%rbp),%r10 82d: 0f 1f 00 nopl (%rax) 830: 48 8b 85 58 ff ff ff mov -0xa8(%rbp),%rax 837: 48 85 c0 test %rax,%rax 83a: 74 09 je 845 <change_protection+0x355> 83c: 65 48 01 04 25 00 00 add %rax,%gs:0x0 843: 00 00 841: R_X86_64_32S vm_event_states+0x170 845: 48 8b 75 88 mov -0x78(%rbp),%rsi 849: 48 01 b5 68 ff ff ff add %rsi,-0x98(%rbp) 850: 49 83 c5 08 add $0x8,%r13 854: 49 39 da cmp %rbx,%r10 857: 0f 84 63 ff ff ff je 7c0 <change_protection+0x2d0> 85d: 49 89 de mov %rbx,%r14 860: e9 c5 fd ff ff jmpq 62a <change_protection+0x13a> 865: 0f 1f 00 nopl (%rax) 868: 0f 0b ud2 86a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) 870: 49 8b 04 24 mov (%r12),%rax 874: 48 85 c0 test %rax,%rax 877: 0f 84 2b ff ff ff je 7a8 <change_protection+0x2b8> 87d: 48 89 c2 mov %rax,%rdx 880: 81 e2 01 02 00 00 and $0x201,%edx 886: 48 81 fa 00 02 00 00 cmp $0x200,%rdx 88d: 0f 84 84 fe ff ff je 717 <change_protection+0x227> 893: 48 be fb 0f 00 00 00 movabs $0xffffc00000000ffb,%rsi 89a: c0 ff ff 89d: 48 21 f0 and %rsi,%rax 8a0: 48 83 f8 63 cmp $0x63,%rax 8a4: 0f 84 6d fe ff ff je 717 <change_protection+0x227> 8aa: 4c 89 e7 mov %r12,%rdi 8ad: e8 00 00 00 00 callq 8b2 <change_protection+0x3c2> 8ae: R_X86_64_PC32 pmd_clear_bad-0x4 8b2: e9 f1 fe ff ff jmpq 7a8 <change_protection+0x2b8> 8b7: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1) 8be: 00 00 8c0: e8 00 00 00 00 callq 8c5 <change_protection+0x3d5> 8c1: R_X86_64_PC32 hugetlb_change_protection-0x4 8c5: 48 89 45 a8 mov %rax,-0x58(%rbp) 8c9: 48 8b 45 a8 mov -0x58(%rbp),%rax 8cd: 48 81 c4 98 00 00 00 add $0x98,%rsp 8d4: 5b pop %rbx 8d5: 41 5c pop %r12 8d7: 41 5d pop %r13 8d9: 41 5e pop %r14 8db: 41 5f pop %r15 8dd: 5d pop %rbp 8de: c3 retq 8df: 90 nop 8e0: 44 8b 45 9c mov -0x64(%rbp),%r8d 8e4: 4c 89 f2 mov %r14,%rdx 8e7: 4c 89 e6 mov %r12,%rsi 8ea: 48 8b 4d b8 mov -0x48(%rbp),%rcx 8ee: 48 8b 7d c8 mov -0x38(%rbp),%rdi 8f2: e8 00 00 00 00 callq 8f7 <change_protection+0x407> 8f3: R_X86_64_PC32 change_huge_pmd-0x4 8f7: 85 c0 test %eax,%eax 8f9: 0f 84 85 fe ff ff je 784 <change_protection+0x294> 8ff: 3d 00 02 00 00 cmp $0x200,%eax 904: 0f 85 9e fe ff ff jne 7a8 <change_protection+0x2b8> 90a: 48 81 45 88 00 02 00 addq $0x200,-0x78(%rbp) 911: 00 912: 48 83 85 58 ff ff ff addq $0x1,-0xa8(%rbp) 919: 01 91a: e9 89 fe ff ff jmpq 7a8 <change_protection+0x2b8> 91f: 90 nop 920: 48 83 7d a8 00 cmpq $0x0,-0x58(%rbp) 925: 4c 8b 7d d0 mov -0x30(%rbp),%r15 929: 74 18 je 943 <change_protection+0x453> 92b: 48 8b 45 c8 mov -0x38(%rbp),%rax 92f: 4c 89 fa mov %r15,%rdx 932: 48 8b 75 c0 mov -0x40(%rbp),%rsi 936: 48 8b 48 50 mov 0x50(%rax),%rcx 93a: 48 8b 78 40 mov 0x40(%rax),%rdi 93e: e8 00 00 00 00 callq 943 <change_protection+0x453> 93f: R_X86_64_PC32 flush_tlb_mm_range-0x4 943: 48 8b 45 80 mov -0x80(%rbp),%rax 947: c6 80 dc 08 00 00 00 movb $0x0,0x8dc(%rax) 94e: e9 76 ff ff ff jmpq 8c9 <change_protection+0x3d9> 953: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 958: 4c 89 ff mov %r15,%rdi 95b: e8 00 00 00 00 callq 960 <change_protection+0x470> 95c: R_X86_64_PC32 pgd_clear_bad-0x4 960: e9 73 fe ff ff jmpq 7d8 <change_protection+0x2e8> 965: 0f 1f 00 nopl (%rax) 968: 4c 89 ef mov %r13,%rdi 96b: 4c 89 55 90 mov %r10,-0x70(%rbp) 96f: e8 00 00 00 00 callq 974 <change_protection+0x484> 970: R_X86_64_PC32 pud_clear_bad-0x4 974: 4c 8b 55 90 mov -0x70(%rbp),%r10 978: e9 d3 fe ff ff jmpq 850 <change_protection+0x360> 97d: 0f 1f 00 nopl (%rax) 980: 0f 0b ud2 982: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) 988: 48 89 da mov %rbx,%rdx 98b: 4c 89 f6 mov %r14,%rsi 98e: 48 89 c7 mov %rax,%rdi 991: e8 00 00 00 00 callq 996 <change_protection+0x4a6> 992: R_X86_64_PC32 __mmu_notifier_invalidate_range_start-0x4 996: e9 99 fd ff ff jmpq 734 <change_protection+0x244> 99b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 9a0: 0f 0b ud2 9a2: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) 9a8: 48 8b 7d c8 mov -0x38(%rbp),%rdi 9ac: 4c 89 e2 mov %r12,%rdx 9af: 4c 89 f6 mov %r14,%rsi 9b2: e8 00 00 00 00 callq 9b7 <change_protection+0x4c7> 9b3: R_X86_64_PC32 __split_huge_page_pmd-0x4 9b7: e9 c8 fd ff ff jmpq 784 <change_protection+0x294> 9bc: 0f 1f 40 00 nopl 0x0(%rax) 9c0: 0f 0b ud2 9c2: 66 66 66 66 66 2e 0f data32 data32 data32 data32 nopw %cs:0x0(%rax,%rax,1) 9c9: 1f 84 00 00 00 00 00 > I've been rather assuming that the 9d340902 seen in many of the > registers in that Aug26 dump is the pte val in question: that's > SOFT_DIRTY|PROTNONE|RW. > > I think RW on PROTNONE is unusual but not impossible (migration entry > replacement racing with mprotect setting PROT_NONE, after it's updated > vm_page_prot, before it's reached the page table). But exciting though > that line of thought is, I cannot actually bring it to a pte_mknuma bug, > or any bug at all. > > Mel, no way can it be the cause of this bug - unless Sasha's later > traces actually show a different stack - but I don't see the call > to change_prot_numa() from queue_pages_range() sharing the same > avoidance of PROT_NONE that task_numa_work() has (though it does > have an outdated comment about PROT_NONE which should be removed). > So I think that site probably does need PROT_NONE checking added. I've spotted a new trace in overnight fuzzing, it could be related to this issue: [ 3494.324839] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 3494.332153] Dumping ftrace buffer: [ 3494.332153] (ftrace buffer empty) [ 3494.332153] Modules linked in: [ 3494.332153] CPU: 8 PID: 2727 Comm: trinity-c929 Not tainted 3.17.0-rc4-next-20140909-sasha-00032-gc16d47b #1135 [ 3494.332153] task: ffff88047e52b000 ti: ffff8804d491c000 task.ti: ffff8804d491c000 [ 3494.332153] RIP: task_numa_work (include/linux/mempolicy.h:177 kernel/sched/fair.c:1956) [ 3494.332153] RSP: 0000:ffff8804d491feb8 EFLAGS: 00010206 [ 3494.332153] RAX: 0000000000000000 RBX: ffff8804bf4e8000 RCX: 000000000000e8e8 [ 3494.343974] RDX: 000000000000000a RSI: 0000000000000000 RDI: ffff8804bd6d4da8 [ 3494.343974] RBP: ffff8804d491fef8 R08: ffff8804bf4e84c8 R09: 0000000000000000 [ 3494.343974] R10: 00007f53e443c000 R11: 0000000000000001 R12: 00007f53e443c000 [ 3494.343974] R13: 000000000000dc51 R14: 006f732e61727478 R15: ffff88047e52b000 [ 3494.343974] FS: 00007f53e463f700(0000) GS:ffff880277e00000(0000) knlGS:0000000000000000 [ 3494.343974] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 3494.369895] CR2: 0000000001670fa8 CR3: 0000000283562000 CR4: 00000000000006a0 [ 3494.369895] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3494.369895] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 [ 3494.380081] Stack: [ 3494.380081] ffff8804bf4e80a8 0000000000000014 00007f53e4437000 0000000000000000 [ 3494.380081] ffffffff9b976e70 ffff88047e52bbd8 ffff88047e52b000 0000000000000000 [ 3494.380081] ffff8804d491ff28 ffffffff95193d84 0000000000000002 ffff8804d491ff58 [ 3494.380081] Call Trace: [ 3494.380081] task_work_run (kernel/task_work.c:125 (discriminator 1)) [ 3494.380081] do_notify_resume (include/linux/tracehook.h:190 arch/x86/kernel/signal.c:758) [ 3494.380081] retint_signal (arch/x86/kernel/entry_64.S:918) [ 3494.380081] Code: e8 1e e5 01 00 48 89 df 4c 89 e6 e8 a3 2d 13 00 49 89 c6 48 85 c0 0f 84 07 02 00 00 48 c7 45 c8 00 00 00 00 0f 1f 80 00 00 00 00 <49> f7 46 50 00 44 00 00 0f 85 42 01 00 00 49 8b 86 a0 00 00 00 All code ======== 0: e8 1e e5 01 00 callq 0x1e523 5: 48 89 df mov %rbx,%rdi 8: 4c 89 e6 mov %r12,%rsi b: e8 a3 2d 13 00 callq 0x132db3 10: 49 89 c6 mov %rax,%r14 13: 48 85 c0 test %rax,%rax 16: 0f 84 07 02 00 00 je 0x223 1c: 48 c7 45 c8 00 00 00 movq $0x0,-0x38(%rbp) 23: 00 24: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 2b:* 49 f7 46 50 00 44 00 testq $0x4400,0x50(%r14) <-- trapping instruction 32: 00 33: 0f 85 42 01 00 00 jne 0x17b 39: 49 8b 86 a0 00 00 00 mov 0xa0(%r14),%rax ... Code starting with the faulting instruction =========================================== 0: 49 f7 46 50 00 44 00 testq $0x4400,0x50(%r14) 7: 00 8: 0f 85 42 01 00 00 jne 0x150 e: 49 8b 86 a0 00 00 00 mov 0xa0(%r14),%rax ... [ 3494.380081] RIP task_numa_work (include/linux/mempolicy.h:177 kernel/sched/fair.c:1956) [ 3494.380081] RSP <ffff8804d491feb8> Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-10 13:12 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-10 13:12 UTC (permalink / raw) To: Hugh Dickins Cc: Mel Gorman, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/09/2014 10:45 PM, Hugh Dickins wrote: > Sasha, you say you're getting plenty of these now, but I've only seen > the dump for one of them, on Aug26: please post a few more dumps, so > that we can look for commonality. I wasn't saving older logs for this issue so I only have 2 traces from tonight. If that's not enough please let me know and I'll try to add a few more. [ 1125.600123] kernel BUG at include/asm-generic/pgtable.h:724! [ 1125.600123] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 1125.600123] Dumping ftrace buffer: [ 1125.600123] (ftrace buffer empty) [ 1125.600123] Modules linked in: [ 1125.600123] CPU: 16 PID: 11903 Comm: trinity-c517 Not tainted 3.17.0-rc4-next-20140909-sasha-00032-gc16d47b #1135 [ 1125.600123] task: ffff880661730000 ti: ffff880582c20000 task.ti: ffff880582c20000 [ 1125.600123] RIP: 0010:[<ffffffffa32e500a>] [<ffffffffa32e500a>] change_pte_range+0x4ea/0x4f0 [ 1125.600123] RSP: 0018:ffff880582c23d68 EFLAGS: 00010246 [ 1125.600123] RAX: 0000000936d9a900 RBX: 00007ffdb17c8000 RCX: 0000000000000100 [ 1125.600123] RDX: 0000000936d9a900 RSI: 00007ffdb17c8000 RDI: 0000000936d9a900 [ 1125.600123] RBP: ffff880582c23dc8 R08: ffff8802a8f2d400 R09: 0000000000b56000 [ 1125.600123] R10: 0000000000020201 R11: 0000000000000008 R12: ffff88004dd6ee40 [ 1125.600123] R13: 8000000000000025 R14: 00007ffdb1800000 R15: ffffc00000000fff [ 1125.600123] FS: 00007ffdb6382700(0000) GS:ffff880278200000(0000) knlGS:0000000000000000 [ 1125.600123] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1125.600123] CR2: 00007ffdb617e60c CR3: 000000050ff12000 CR4: 00000000000006a0 [ 1125.600123] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1125.600123] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 [ 1125.600123] Stack: [ 1125.600123] 0000000000000001 0000000936d9a900 0000000000000046 ffff8804bd549f40 [ 1125.600123] 000000001f989000 ffff8802a8f2d400 ffff88051f989000 00007f9f40604cfdb1ac8000 [ 1125.600123] ffff88032fcc3c58 00007ffdb16df000 00007ffdb16df000 00007ffdb1800000 [ 1125.600123] Call Trace: [ 1125.600123] [<ffffffffa32e52c4>] change_protection+0x2b4/0x4e0 [ 1125.600123] [<ffffffffa32fefdb>] change_prot_numa+0x1b/0x40 [ 1125.600123] [<ffffffffa31add86>] task_numa_work+0x1f6/0x330 [ 1125.600123] [<ffffffffa3193d84>] task_work_run+0xc4/0xf0 [ 1125.600123] [<ffffffffa3071477>] do_notify_resume+0x97/0xb0 [ 1125.600123] [<ffffffffa650daea>] int_signal+0x12/0x17 [ 1125.600123] Code: 66 90 48 8b 7d b8 e8 f6 75 22 03 48 8b 45 b0 e9 6f ff ff ff 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b <0f> 0b 0f 0b 0f 0b 66 66 66 66 90 55 48 89 e5 41 57 49 89 d7 41 [ 1125.600123] RIP [<ffffffffa32e500a>] change_pte_range+0x4ea/0x4f0 [ 1125.600123] RSP <ffff880582c23d68> [ 3131.084176] kernel BUG at include/asm-generic/pgtable.h:724! [ 3131.087358] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 3131.090143] Dumping ftrace buffer: [ 3131.090143] (ftrace buffer empty) [ 3131.090143] Modules linked in: [ 3131.090143] CPU: 8 PID: 20595 Comm: trinity-c34 Not tainted 3.17.0-rc4-next-20140909-sasha-00032-gc16d47b #1135 [ 3131.090143] task: ffff8801ded60000 ti: ffff8803204ec000 task.ti: ffff8803204ec000 [ 3131.090143] RIP: 0010:[<ffffffffa72e500a>] [<ffffffffa72e500a>] change_pte_range+0x4ea/0x4f0 [ 3131.090143] RSP: 0000:ffff8803204efd68 EFLAGS: 00010246 [ 3131.090143] RAX: 0000000971bba900 RBX: 00007ffda1d4d000 RCX: 0000000000000100 [ 3131.090143] RDX: 0000000971bba900 RSI: 00007ffda1d4d000 RDI: 0000000971bba900 [ 3131.120281] RBP: ffff8803204efdc8 R08: ffff88026bed8800 R09: 0000000000b48000 [ 3131.120281] R10: 0000000000076501 R11: 0000000000000008 R12: ffff8801ca071a68 [ 3131.120281] R13: 8000000000000025 R14: 00007ffda1dbf000 R15: ffffc00000000fff [ 3131.120281] FS: 00007ffda5cd4700(0000) GS:ffff880277e00000(0000) knlGS:0000000000000000 [ 3131.120281] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3131.120281] CR2: 00000000025d6000 CR3: 00000004bcde2000 CR4: 00000000000006a0 [ 3131.120281] Stack: [ 3131.120281] 0000000000000001 0000000971bba900 000000000000005c ffff8800661a7b60 [ 3131.120281] 00000000f4953000 ffff88026bed8800 ffff8801f4953000 00007ffda1dbf000 [ 3131.120281] ffff8802b3319870 00007ffda1c1b000 00007ffda1c1b000 00007ffda1dbf000 [ 3131.120281] Call Trace: [ 3131.120281] [<ffffffffa72e52c4>] change_protection+0x2b4/0x4e0 [ 3131.120281] [<ffffffffa72fefdb>] change_prot_numa+0x1b/0x40 [ 3131.120281] [<ffffffffa71add86>] task_numa_work+0x1f6/0x330 [ 3131.120281] [<ffffffffa7193d84>] task_work_run+0xc4/0xf0 [ 3131.120281] [<ffffffffa7071477>] do_notify_resume+0x97/0xb0 [ 3131.120281] [<ffffffffaa50e6ae>] retint_signal+0x4d/0x9f [ 3131.120281] Code: 66 90 48 8b 7d b8 e8 f6 75 22 03 48 8b 45 b0 e9 6f ff ff ff 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b <0f> 0b 0f 0b 0f 0b 66 66 66 66 90 55 48 89 e5 41 57 49 89 d7 41 [ 3131.120281] RIP [<ffffffffa72e500a>] change_pte_range+0x4ea/0x4f0 [ 3131.120281] RSP <ffff8803204efd68> > And please attach a disassembly of change_protection_range() (noting > which of the dumps it corresponds to, in case it has changed around): > "Code" just shows a cluster of ud2s for the unlikely bugs at end of the > function, we cannot tell at all what should be in the registers by then. change_protection_range() got inlined into change_protection(), it applies to both traces above: 00000000000004f0 <change_protection>: 4f0: e8 00 00 00 00 callq 4f5 <change_protection+0x5> 4f1: R_X86_64_PC32 __fentry__-0x4 4f5: 55 push %rbp 4f6: 48 89 e5 mov %rsp,%rbp 4f9: 41 57 push %r15 4fb: 49 89 d7 mov %rdx,%r15 4fe: 41 56 push %r14 500: 41 55 push %r13 502: 41 54 push %r12 504: 53 push %rbx 505: 48 81 ec 98 00 00 00 sub $0x98,%rsp 50c: 48 89 7d c8 mov %rdi,-0x38(%rbp) 510: 48 89 75 c0 mov %rsi,-0x40(%rbp) 514: 48 89 4d b8 mov %rcx,-0x48(%rbp) 518: 44 89 45 98 mov %r8d,-0x68(%rbp) 51c: 44 89 4d 9c mov %r9d,-0x64(%rbp) 520: f6 47 52 40 testb $0x40,0x52(%rdi) 524: 0f 85 96 03 00 00 jne 8c0 <change_protection+0x3d0> 52a: 48 8b 45 c8 mov -0x38(%rbp),%rax 52e: 48 8b 40 40 mov 0x40(%rax),%rax 532: 48 89 45 80 mov %rax,-0x80(%rbp) 536: 48 39 55 c0 cmp %rdx,-0x40(%rbp) 53a: 0f 83 40 04 00 00 jae 980 <change_protection+0x490> 540: 4c 8b 5d c0 mov -0x40(%rbp),%r11 544: 48 8b 4d 80 mov -0x80(%rbp),%rcx 548: 4c 89 d8 mov %r11,%rax 54b: 48 c1 e8 24 shr $0x24,%rax 54f: c6 81 dc 08 00 00 01 movb $0x1,0x8dc(%rcx) 556: 25 f8 0f 00 00 and $0xff8,%eax 55b: 48 03 41 40 add 0x40(%rcx),%rax 55f: 48 8d 52 ff lea -0x1(%rdx),%rdx 563: 4c 89 7d d0 mov %r15,-0x30(%rbp) 567: 49 89 c7 mov %rax,%r15 56a: 48 89 55 b0 mov %rdx,-0x50(%rbp) 56e: 48 c7 45 a8 00 00 00 movq $0x0,-0x58(%rbp) 575: 00 576: 48 b8 00 00 00 00 80 movabs $0x8000000000,%rax 57d: 00 00 00 580: 49 8b 3f mov (%r15),%rdi 583: 49 bd 00 00 00 00 80 movabs $0xffffff8000000000,%r13 58a: ff ff ff 58d: 4c 01 d8 add %r11,%rax 590: 49 21 c5 and %rax,%r13 593: 49 8d 45 ff lea -0x1(%r13),%rax 597: 48 3b 45 b0 cmp -0x50(%rbp),%rax 59b: 4c 0f 43 6d d0 cmovae -0x30(%rbp),%r13 5a0: 48 85 ff test %rdi,%rdi 5a3: 0f 84 2f 02 00 00 je 7d8 <change_protection+0x2e8> 5a9: 48 b8 fb 0f 00 00 00 movabs $0xffffc00000000ffb,%rax 5b0: c0 ff ff 5b3: 48 21 f8 and %rdi,%rax 5b6: 48 83 f8 63 cmp $0x63,%rax 5ba: 0f 85 98 03 00 00 jne 958 <change_protection+0x468> 5c0: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 5c8 <change_protection+0xd8> 5c7: 00 5c3: R_X86_64_PC32 pv_mmu_ops+0xf3 5c8: 0f 84 d2 03 00 00 je 9a0 <change_protection+0x4b0> 5ce: ff 14 25 00 00 00 00 callq *0x0 5d1: R_X86_64_32S pv_mmu_ops+0xf8 5d5: 4c 89 df mov %r11,%rdi 5d8: 4d 89 ea mov %r13,%r10 5db: 4c 89 bd 60 ff ff ff mov %r15,-0xa0(%rbp) 5e2: 48 ba 00 f0 ff ff ff movabs $0x3ffffffff000,%rdx 5e9: 3f 00 00 5ec: 48 c1 ef 1b shr $0x1b,%rdi 5f0: 48 21 d0 and %rdx,%rax 5f3: 48 be 00 00 00 00 00 movabs $0xffff880000000000,%rsi 5fa: 88 ff ff 5fd: 48 c7 85 68 ff ff ff movq $0x0,-0x98(%rbp) 604: 00 00 00 00 608: 81 e7 f8 0f 00 00 and $0xff8,%edi 60e: 48 89 95 70 ff ff ff mov %rdx,-0x90(%rbp) 615: 48 01 f7 add %rsi,%rdi 618: 4c 8d 34 07 lea (%rdi,%rax,1),%r14 61c: 49 8d 45 ff lea -0x1(%r13),%rax 620: 4d 89 f5 mov %r14,%r13 623: 4d 89 de mov %r11,%r14 626: 48 89 45 a0 mov %rax,-0x60(%rbp) 62a: 49 8d 9e 00 00 00 40 lea 0x40000000(%r14),%rbx 631: 49 8b 7d 00 mov 0x0(%r13),%rdi 635: 48 81 e3 00 00 00 c0 and $0xffffffffc0000000,%rbx 63c: 48 8d 43 ff lea -0x1(%rbx),%rax 640: 48 3b 45 a0 cmp -0x60(%rbp),%rax 644: 49 0f 43 da cmovae %r10,%rbx 648: 48 85 ff test %rdi,%rdi 64b: 0f 84 ff 01 00 00 je 850 <change_protection+0x360> 651: 48 b8 98 0f 00 00 00 movabs $0xffffc00000000f98,%rax 658: c0 ff ff 65b: 48 85 c7 test %rax,%rdi 65e: 0f 85 04 03 00 00 jne 968 <change_protection+0x478> 664: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 66c <change_protection+0x17c> 66b: 00 667: R_X86_64_PC32 pv_mmu_ops+0x11b 66c: 0f 84 4e 03 00 00 je 9c0 <change_protection+0x4d0> 672: 48 8b 45 c8 mov -0x38(%rbp),%rax 676: 48 8b 40 40 mov 0x40(%rax),%rax 67a: 48 89 85 78 ff ff ff mov %rax,-0x88(%rbp) 681: ff 14 25 00 00 00 00 callq *0x0 684: R_X86_64_32S pv_mmu_ops+0x120 688: 48 23 85 70 ff ff ff and -0x90(%rbp),%rax 68f: 4d 89 f4 mov %r14,%r12 692: 45 31 db xor %r11d,%r11d 695: 4c 89 ad 48 ff ff ff mov %r13,-0xb8(%rbp) 69c: 49 c1 ec 12 shr $0x12,%r12 6a0: 48 c7 45 88 00 00 00 movq $0x0,-0x78(%rbp) 6a7: 00 6a8: 4d 89 dd mov %r11,%r13 6ab: 41 81 e4 f8 0f 00 00 and $0xff8,%r12d 6b2: 4c 89 95 50 ff ff ff mov %r10,-0xb0(%rbp) 6b9: 48 ba 00 00 00 00 00 movabs $0xffff880000000000,%rdx 6c0: 88 ff ff 6c3: 48 c7 85 58 ff ff ff movq $0x0,-0xa8(%rbp) 6ca: 00 00 00 00 6ce: 49 01 d4 add %rdx,%r12 6d1: 49 01 c4 add %rax,%r12 6d4: 48 8d 43 ff lea -0x1(%rbx),%rax 6d8: 48 89 45 90 mov %rax,-0x70(%rbp) 6dc: 4d 8d be 00 00 20 00 lea 0x200000(%r14),%r15 6e3: 49 8b 3c 24 mov (%r12),%rdi 6e7: 49 81 e7 00 00 e0 ff and $0xffffffffffe00000,%r15 6ee: 49 8d 47 ff lea -0x1(%r15),%rax 6f2: 48 3b 45 90 cmp -0x70(%rbp),%rax 6f6: 4c 0f 43 fb cmovae %rbx,%r15 6fa: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 702 <change_protection+0x212> 701: 00 6fd: R_X86_64_PC32 pv_mmu_ops+0x10b 702: 0f 84 60 01 00 00 je 868 <change_protection+0x378> 708: ff 14 25 00 00 00 00 callq *0x0 70b: R_X86_64_32S pv_mmu_ops+0x110 70f: a8 80 test $0x80,%al 711: 0f 84 59 01 00 00 je 870 <change_protection+0x380> 717: 4d 85 ed test %r13,%r13 71a: 75 18 jne 734 <change_protection+0x244> 71c: 48 8b 85 78 ff ff ff mov -0x88(%rbp),%rax 723: 4d 89 f5 mov %r14,%r13 726: 48 83 b8 c0 04 00 00 cmpq $0x0,0x4c0(%rax) 72d: 00 72e: 0f 85 54 02 00 00 jne 988 <change_protection+0x498> 734: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 73c <change_protection+0x24c> 73b: 00 737: R_X86_64_PC32 pv_mmu_ops+0x10b 73c: 49 8b 3c 24 mov (%r12),%rdi 740: 0f 84 22 01 00 00 je 868 <change_protection+0x378> 746: ff 14 25 00 00 00 00 callq *0x0 749: R_X86_64_32S pv_mmu_ops+0x110 74d: a8 80 test $0x80,%al 74f: 74 33 je 784 <change_protection+0x294> 751: 4c 89 f8 mov %r15,%rax 754: 4c 29 f0 sub %r14,%rax 757: 48 3d 00 00 20 00 cmp $0x200000,%rax 75d: 0f 84 7d 01 00 00 je 8e0 <change_protection+0x3f0> 763: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 76b <change_protection+0x27b> 76a: 00 766: R_X86_64_PC32 pv_mmu_ops+0x10b 76b: 49 8b 3c 24 mov (%r12),%rdi 76f: 0f 84 f3 00 00 00 je 868 <change_protection+0x378> 775: ff 14 25 00 00 00 00 callq *0x0 778: R_X86_64_32S pv_mmu_ops+0x110 77c: a8 80 test $0x80,%al 77e: 0f 85 24 02 00 00 jne 9a8 <change_protection+0x4b8> 784: 8b 45 9c mov -0x64(%rbp),%eax 787: 4c 89 f9 mov %r15,%rcx 78a: 4c 89 f2 mov %r14,%rdx 78d: 4c 89 e6 mov %r12,%rsi 790: 44 8b 4d 98 mov -0x68(%rbp),%r9d 794: 4c 8b 45 b8 mov -0x48(%rbp),%r8 798: 48 8b 7d c8 mov -0x38(%rbp),%rdi 79c: 89 04 24 mov %eax,(%rsp) 79f: e8 5c f8 ff ff callq 0 <change_pte_range> 7a4: 48 01 45 88 add %rax,-0x78(%rbp) 7a8: 49 83 c4 08 add $0x8,%r12 7ac: 4c 39 fb cmp %r15,%rbx 7af: 74 3f je 7f0 <change_protection+0x300> 7b1: 4d 89 fe mov %r15,%r14 7b4: e9 23 ff ff ff jmpq 6dc <change_protection+0x1ec> 7b9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 7c0: 48 8b b5 68 ff ff ff mov -0x98(%rbp),%rsi 7c7: 4d 89 d5 mov %r10,%r13 7ca: 4c 8b bd 60 ff ff ff mov -0xa0(%rbp),%r15 7d1: 48 01 75 a8 add %rsi,-0x58(%rbp) 7d5: 0f 1f 00 nopl (%rax) 7d8: 49 83 c7 08 add $0x8,%r15 7dc: 4c 39 6d d0 cmp %r13,-0x30(%rbp) 7e0: 0f 84 3a 01 00 00 je 920 <change_protection+0x430> 7e6: 4d 89 eb mov %r13,%r11 7e9: e9 88 fd ff ff jmpq 576 <change_protection+0x86> 7ee: 66 90 xchg %ax,%ax 7f0: 4d 89 eb mov %r13,%r11 7f3: 4c 8b 95 50 ff ff ff mov -0xb0(%rbp),%r10 7fa: 4c 8b ad 48 ff ff ff mov -0xb8(%rbp),%r13 801: 4d 85 db test %r11,%r11 804: 74 2a je 830 <change_protection+0x340> 806: 48 8b 85 78 ff ff ff mov -0x88(%rbp),%rax 80d: 48 83 b8 c0 04 00 00 cmpq $0x0,0x4c0(%rax) 814: 00 815: 74 19 je 830 <change_protection+0x340> 817: 48 89 da mov %rbx,%rdx 81a: 4c 89 de mov %r11,%rsi 81d: 48 89 c7 mov %rax,%rdi 820: 4c 89 55 90 mov %r10,-0x70(%rbp) 824: e8 00 00 00 00 callq 829 <change_protection+0x339> 825: R_X86_64_PC32 __mmu_notifier_invalidate_range_end-0x4 829: 4c 8b 55 90 mov -0x70(%rbp),%r10 82d: 0f 1f 00 nopl (%rax) 830: 48 8b 85 58 ff ff ff mov -0xa8(%rbp),%rax 837: 48 85 c0 test %rax,%rax 83a: 74 09 je 845 <change_protection+0x355> 83c: 65 48 01 04 25 00 00 add %rax,%gs:0x0 843: 00 00 841: R_X86_64_32S vm_event_states+0x170 845: 48 8b 75 88 mov -0x78(%rbp),%rsi 849: 48 01 b5 68 ff ff ff add %rsi,-0x98(%rbp) 850: 49 83 c5 08 add $0x8,%r13 854: 49 39 da cmp %rbx,%r10 857: 0f 84 63 ff ff ff je 7c0 <change_protection+0x2d0> 85d: 49 89 de mov %rbx,%r14 860: e9 c5 fd ff ff jmpq 62a <change_protection+0x13a> 865: 0f 1f 00 nopl (%rax) 868: 0f 0b ud2 86a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) 870: 49 8b 04 24 mov (%r12),%rax 874: 48 85 c0 test %rax,%rax 877: 0f 84 2b ff ff ff je 7a8 <change_protection+0x2b8> 87d: 48 89 c2 mov %rax,%rdx 880: 81 e2 01 02 00 00 and $0x201,%edx 886: 48 81 fa 00 02 00 00 cmp $0x200,%rdx 88d: 0f 84 84 fe ff ff je 717 <change_protection+0x227> 893: 48 be fb 0f 00 00 00 movabs $0xffffc00000000ffb,%rsi 89a: c0 ff ff 89d: 48 21 f0 and %rsi,%rax 8a0: 48 83 f8 63 cmp $0x63,%rax 8a4: 0f 84 6d fe ff ff je 717 <change_protection+0x227> 8aa: 4c 89 e7 mov %r12,%rdi 8ad: e8 00 00 00 00 callq 8b2 <change_protection+0x3c2> 8ae: R_X86_64_PC32 pmd_clear_bad-0x4 8b2: e9 f1 fe ff ff jmpq 7a8 <change_protection+0x2b8> 8b7: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1) 8be: 00 00 8c0: e8 00 00 00 00 callq 8c5 <change_protection+0x3d5> 8c1: R_X86_64_PC32 hugetlb_change_protection-0x4 8c5: 48 89 45 a8 mov %rax,-0x58(%rbp) 8c9: 48 8b 45 a8 mov -0x58(%rbp),%rax 8cd: 48 81 c4 98 00 00 00 add $0x98,%rsp 8d4: 5b pop %rbx 8d5: 41 5c pop %r12 8d7: 41 5d pop %r13 8d9: 41 5e pop %r14 8db: 41 5f pop %r15 8dd: 5d pop %rbp 8de: c3 retq 8df: 90 nop 8e0: 44 8b 45 9c mov -0x64(%rbp),%r8d 8e4: 4c 89 f2 mov %r14,%rdx 8e7: 4c 89 e6 mov %r12,%rsi 8ea: 48 8b 4d b8 mov -0x48(%rbp),%rcx 8ee: 48 8b 7d c8 mov -0x38(%rbp),%rdi 8f2: e8 00 00 00 00 callq 8f7 <change_protection+0x407> 8f3: R_X86_64_PC32 change_huge_pmd-0x4 8f7: 85 c0 test %eax,%eax 8f9: 0f 84 85 fe ff ff je 784 <change_protection+0x294> 8ff: 3d 00 02 00 00 cmp $0x200,%eax 904: 0f 85 9e fe ff ff jne 7a8 <change_protection+0x2b8> 90a: 48 81 45 88 00 02 00 addq $0x200,-0x78(%rbp) 911: 00 912: 48 83 85 58 ff ff ff addq $0x1,-0xa8(%rbp) 919: 01 91a: e9 89 fe ff ff jmpq 7a8 <change_protection+0x2b8> 91f: 90 nop 920: 48 83 7d a8 00 cmpq $0x0,-0x58(%rbp) 925: 4c 8b 7d d0 mov -0x30(%rbp),%r15 929: 74 18 je 943 <change_protection+0x453> 92b: 48 8b 45 c8 mov -0x38(%rbp),%rax 92f: 4c 89 fa mov %r15,%rdx 932: 48 8b 75 c0 mov -0x40(%rbp),%rsi 936: 48 8b 48 50 mov 0x50(%rax),%rcx 93a: 48 8b 78 40 mov 0x40(%rax),%rdi 93e: e8 00 00 00 00 callq 943 <change_protection+0x453> 93f: R_X86_64_PC32 flush_tlb_mm_range-0x4 943: 48 8b 45 80 mov -0x80(%rbp),%rax 947: c6 80 dc 08 00 00 00 movb $0x0,0x8dc(%rax) 94e: e9 76 ff ff ff jmpq 8c9 <change_protection+0x3d9> 953: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 958: 4c 89 ff mov %r15,%rdi 95b: e8 00 00 00 00 callq 960 <change_protection+0x470> 95c: R_X86_64_PC32 pgd_clear_bad-0x4 960: e9 73 fe ff ff jmpq 7d8 <change_protection+0x2e8> 965: 0f 1f 00 nopl (%rax) 968: 4c 89 ef mov %r13,%rdi 96b: 4c 89 55 90 mov %r10,-0x70(%rbp) 96f: e8 00 00 00 00 callq 974 <change_protection+0x484> 970: R_X86_64_PC32 pud_clear_bad-0x4 974: 4c 8b 55 90 mov -0x70(%rbp),%r10 978: e9 d3 fe ff ff jmpq 850 <change_protection+0x360> 97d: 0f 1f 00 nopl (%rax) 980: 0f 0b ud2 982: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) 988: 48 89 da mov %rbx,%rdx 98b: 4c 89 f6 mov %r14,%rsi 98e: 48 89 c7 mov %rax,%rdi 991: e8 00 00 00 00 callq 996 <change_protection+0x4a6> 992: R_X86_64_PC32 __mmu_notifier_invalidate_range_start-0x4 996: e9 99 fd ff ff jmpq 734 <change_protection+0x244> 99b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 9a0: 0f 0b ud2 9a2: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) 9a8: 48 8b 7d c8 mov -0x38(%rbp),%rdi 9ac: 4c 89 e2 mov %r12,%rdx 9af: 4c 89 f6 mov %r14,%rsi 9b2: e8 00 00 00 00 callq 9b7 <change_protection+0x4c7> 9b3: R_X86_64_PC32 __split_huge_page_pmd-0x4 9b7: e9 c8 fd ff ff jmpq 784 <change_protection+0x294> 9bc: 0f 1f 40 00 nopl 0x0(%rax) 9c0: 0f 0b ud2 9c2: 66 66 66 66 66 2e 0f data32 data32 data32 data32 nopw %cs:0x0(%rax,%rax,1) 9c9: 1f 84 00 00 00 00 00 > I've been rather assuming that the 9d340902 seen in many of the > registers in that Aug26 dump is the pte val in question: that's > SOFT_DIRTY|PROTNONE|RW. > > I think RW on PROTNONE is unusual but not impossible (migration entry > replacement racing with mprotect setting PROT_NONE, after it's updated > vm_page_prot, before it's reached the page table). But exciting though > that line of thought is, I cannot actually bring it to a pte_mknuma bug, > or any bug at all. > > Mel, no way can it be the cause of this bug - unless Sasha's later > traces actually show a different stack - but I don't see the call > to change_prot_numa() from queue_pages_range() sharing the same > avoidance of PROT_NONE that task_numa_work() has (though it does > have an outdated comment about PROT_NONE which should be removed). > So I think that site probably does need PROT_NONE checking added. I've spotted a new trace in overnight fuzzing, it could be related to this issue: [ 3494.324839] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 3494.332153] Dumping ftrace buffer: [ 3494.332153] (ftrace buffer empty) [ 3494.332153] Modules linked in: [ 3494.332153] CPU: 8 PID: 2727 Comm: trinity-c929 Not tainted 3.17.0-rc4-next-20140909-sasha-00032-gc16d47b #1135 [ 3494.332153] task: ffff88047e52b000 ti: ffff8804d491c000 task.ti: ffff8804d491c000 [ 3494.332153] RIP: task_numa_work (include/linux/mempolicy.h:177 kernel/sched/fair.c:1956) [ 3494.332153] RSP: 0000:ffff8804d491feb8 EFLAGS: 00010206 [ 3494.332153] RAX: 0000000000000000 RBX: ffff8804bf4e8000 RCX: 000000000000e8e8 [ 3494.343974] RDX: 000000000000000a RSI: 0000000000000000 RDI: ffff8804bd6d4da8 [ 3494.343974] RBP: ffff8804d491fef8 R08: ffff8804bf4e84c8 R09: 0000000000000000 [ 3494.343974] R10: 00007f53e443c000 R11: 0000000000000001 R12: 00007f53e443c000 [ 3494.343974] R13: 000000000000dc51 R14: 006f732e61727478 R15: ffff88047e52b000 [ 3494.343974] FS: 00007f53e463f700(0000) GS:ffff880277e00000(0000) knlGS:0000000000000000 [ 3494.343974] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 3494.369895] CR2: 0000000001670fa8 CR3: 0000000283562000 CR4: 00000000000006a0 [ 3494.369895] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3494.369895] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 [ 3494.380081] Stack: [ 3494.380081] ffff8804bf4e80a8 0000000000000014 00007f53e4437000 0000000000000000 [ 3494.380081] ffffffff9b976e70 ffff88047e52bbd8 ffff88047e52b000 0000000000000000 [ 3494.380081] ffff8804d491ff28 ffffffff95193d84 0000000000000002 ffff8804d491ff58 [ 3494.380081] Call Trace: [ 3494.380081] task_work_run (kernel/task_work.c:125 (discriminator 1)) [ 3494.380081] do_notify_resume (include/linux/tracehook.h:190 arch/x86/kernel/signal.c:758) [ 3494.380081] retint_signal (arch/x86/kernel/entry_64.S:918) [ 3494.380081] Code: e8 1e e5 01 00 48 89 df 4c 89 e6 e8 a3 2d 13 00 49 89 c6 48 85 c0 0f 84 07 02 00 00 48 c7 45 c8 00 00 00 00 0f 1f 80 00 00 00 00 <49> f7 46 50 00 44 00 00 0f 85 42 01 00 00 49 8b 86 a0 00 00 00 All code ======== 0: e8 1e e5 01 00 callq 0x1e523 5: 48 89 df mov %rbx,%rdi 8: 4c 89 e6 mov %r12,%rsi b: e8 a3 2d 13 00 callq 0x132db3 10: 49 89 c6 mov %rax,%r14 13: 48 85 c0 test %rax,%rax 16: 0f 84 07 02 00 00 je 0x223 1c: 48 c7 45 c8 00 00 00 movq $0x0,-0x38(%rbp) 23: 00 24: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 2b:* 49 f7 46 50 00 44 00 testq $0x4400,0x50(%r14) <-- trapping instruction 32: 00 33: 0f 85 42 01 00 00 jne 0x17b 39: 49 8b 86 a0 00 00 00 mov 0xa0(%r14),%rax ... Code starting with the faulting instruction =========================================== 0: 49 f7 46 50 00 44 00 testq $0x4400,0x50(%r14) 7: 00 8: 0f 85 42 01 00 00 jne 0x150 e: 49 8b 86 a0 00 00 00 mov 0xa0(%r14),%rax ... [ 3494.380081] RIP task_numa_work (include/linux/mempolicy.h:177 kernel/sched/fair.c:1956) [ 3494.380081] RSP <ffff8804d491feb8> 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-10 13:12 ` Sasha Levin @ 2014-09-10 13:40 ` Mel Gorman -1 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-09-10 13:40 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Wed, Sep 10, 2014 at 09:12:04AM -0400, Sasha Levin wrote: > <SNIP, haven't digested the rest> > > I've spotted a new trace in overnight fuzzing, it could be related to this issue: > > [ 3494.324839] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 3494.332153] Dumping ftrace buffer: > [ 3494.332153] (ftrace buffer empty) > [ 3494.332153] Modules linked in: > [ 3494.332153] CPU: 8 PID: 2727 Comm: trinity-c929 Not tainted 3.17.0-rc4-next-20140909-sasha-00032-gc16d47b #1135 > [ 3494.332153] task: ffff88047e52b000 ti: ffff8804d491c000 task.ti: ffff8804d491c000 > [ 3494.332153] RIP: task_numa_work (include/linux/mempolicy.h:177 kernel/sched/fair.c:1956) > [ 3494.332153] RSP: 0000:ffff8804d491feb8 EFLAGS: 00010206 > [ 3494.332153] RAX: 0000000000000000 RBX: ffff8804bf4e8000 RCX: 000000000000e8e8 > [ 3494.343974] RDX: 000000000000000a RSI: 0000000000000000 RDI: ffff8804bd6d4da8 > [ 3494.343974] RBP: ffff8804d491fef8 R08: ffff8804bf4e84c8 R09: 0000000000000000 > [ 3494.343974] R10: 00007f53e443c000 R11: 0000000000000001 R12: 00007f53e443c000 > [ 3494.343974] R13: 000000000000dc51 R14: 006f732e61727478 R15: ffff88047e52b000 > [ 3494.343974] FS: 00007f53e463f700(0000) GS:ffff880277e00000(0000) knlGS:0000000000000000 > [ 3494.343974] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 3494.369895] CR2: 0000000001670fa8 CR3: 0000000283562000 CR4: 00000000000006a0 > [ 3494.369895] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 3494.369895] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 > [ 3494.380081] Stack: > [ 3494.380081] ffff8804bf4e80a8 0000000000000014 00007f53e4437000 0000000000000000 > [ 3494.380081] ffffffff9b976e70 ffff88047e52bbd8 ffff88047e52b000 0000000000000000 > [ 3494.380081] ffff8804d491ff28 ffffffff95193d84 0000000000000002 ffff8804d491ff58 > [ 3494.380081] Call Trace: > [ 3494.380081] task_work_run (kernel/task_work.c:125 (discriminator 1)) > [ 3494.380081] do_notify_resume (include/linux/tracehook.h:190 arch/x86/kernel/signal.c:758) > [ 3494.380081] retint_signal (arch/x86/kernel/entry_64.S:918) > [ 3494.380081] Code: e8 1e e5 01 00 48 89 df 4c 89 e6 e8 a3 2d 13 00 49 89 c6 48 85 c0 0f 84 07 02 00 00 48 c7 45 c8 00 00 00 00 0f 1f 80 00 00 00 00 <49> f7 46 50 00 44 00 00 0f 85 42 01 00 00 49 8b 86 a0 00 00 00 Shot in dark, can you test this please? Pagetable teardown can schedule and I'm wondering if we are trying to add hinting faults to an address space that is in the process of going away. The TASK_DEAD check is bogus so replacing it. diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7ea6006..007fc1c 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -1810,7 +1810,7 @@ void task_numa_fault(int last_cpupid, int mem_node, int pages, int flags) return; /* Do not worry about placement if exiting */ - if (p->state == TASK_DEAD) + if (p->flags & PF_EXITING) return; /* Allocate buffer to track faults on a per-node basis */ ^ permalink raw reply related [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-10 13:40 ` Mel Gorman 0 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-09-10 13:40 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Wed, Sep 10, 2014 at 09:12:04AM -0400, Sasha Levin wrote: > <SNIP, haven't digested the rest> > > I've spotted a new trace in overnight fuzzing, it could be related to this issue: > > [ 3494.324839] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 3494.332153] Dumping ftrace buffer: > [ 3494.332153] (ftrace buffer empty) > [ 3494.332153] Modules linked in: > [ 3494.332153] CPU: 8 PID: 2727 Comm: trinity-c929 Not tainted 3.17.0-rc4-next-20140909-sasha-00032-gc16d47b #1135 > [ 3494.332153] task: ffff88047e52b000 ti: ffff8804d491c000 task.ti: ffff8804d491c000 > [ 3494.332153] RIP: task_numa_work (include/linux/mempolicy.h:177 kernel/sched/fair.c:1956) > [ 3494.332153] RSP: 0000:ffff8804d491feb8 EFLAGS: 00010206 > [ 3494.332153] RAX: 0000000000000000 RBX: ffff8804bf4e8000 RCX: 000000000000e8e8 > [ 3494.343974] RDX: 000000000000000a RSI: 0000000000000000 RDI: ffff8804bd6d4da8 > [ 3494.343974] RBP: ffff8804d491fef8 R08: ffff8804bf4e84c8 R09: 0000000000000000 > [ 3494.343974] R10: 00007f53e443c000 R11: 0000000000000001 R12: 00007f53e443c000 > [ 3494.343974] R13: 000000000000dc51 R14: 006f732e61727478 R15: ffff88047e52b000 > [ 3494.343974] FS: 00007f53e463f700(0000) GS:ffff880277e00000(0000) knlGS:0000000000000000 > [ 3494.343974] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 3494.369895] CR2: 0000000001670fa8 CR3: 0000000283562000 CR4: 00000000000006a0 > [ 3494.369895] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 3494.369895] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 > [ 3494.380081] Stack: > [ 3494.380081] ffff8804bf4e80a8 0000000000000014 00007f53e4437000 0000000000000000 > [ 3494.380081] ffffffff9b976e70 ffff88047e52bbd8 ffff88047e52b000 0000000000000000 > [ 3494.380081] ffff8804d491ff28 ffffffff95193d84 0000000000000002 ffff8804d491ff58 > [ 3494.380081] Call Trace: > [ 3494.380081] task_work_run (kernel/task_work.c:125 (discriminator 1)) > [ 3494.380081] do_notify_resume (include/linux/tracehook.h:190 arch/x86/kernel/signal.c:758) > [ 3494.380081] retint_signal (arch/x86/kernel/entry_64.S:918) > [ 3494.380081] Code: e8 1e e5 01 00 48 89 df 4c 89 e6 e8 a3 2d 13 00 49 89 c6 48 85 c0 0f 84 07 02 00 00 48 c7 45 c8 00 00 00 00 0f 1f 80 00 00 00 00 <49> f7 46 50 00 44 00 00 0f 85 42 01 00 00 49 8b 86 a0 00 00 00 Shot in dark, can you test this please? Pagetable teardown can schedule and I'm wondering if we are trying to add hinting faults to an address space that is in the process of going away. The TASK_DEAD check is bogus so replacing it. diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7ea6006..007fc1c 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -1810,7 +1810,7 @@ void task_numa_fault(int last_cpupid, int mem_node, int pages, int flags) return; /* Do not worry about placement if exiting */ - if (p->state == TASK_DEAD) + if (p->flags & PF_EXITING) return; /* Allocate buffer to track faults on a per-node basis */ -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-10 13:40 ` Mel Gorman @ 2014-09-10 16:44 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-10 16:44 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/10/2014 09:40 AM, Mel Gorman wrote: > On Wed, Sep 10, 2014 at 09:12:04AM -0400, Sasha Levin wrote: >> <SNIP, haven't digested the rest> >> >> I've spotted a new trace in overnight fuzzing, it could be related to this issue: >> >> [ 3494.324839] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC >> [ 3494.332153] Dumping ftrace buffer: >> [ 3494.332153] (ftrace buffer empty) >> [ 3494.332153] Modules linked in: >> [ 3494.332153] CPU: 8 PID: 2727 Comm: trinity-c929 Not tainted 3.17.0-rc4-next-20140909-sasha-00032-gc16d47b #1135 >> [ 3494.332153] task: ffff88047e52b000 ti: ffff8804d491c000 task.ti: ffff8804d491c000 >> [ 3494.332153] RIP: task_numa_work (include/linux/mempolicy.h:177 kernel/sched/fair.c:1956) >> [ 3494.332153] RSP: 0000:ffff8804d491feb8 EFLAGS: 00010206 >> [ 3494.332153] RAX: 0000000000000000 RBX: ffff8804bf4e8000 RCX: 000000000000e8e8 >> [ 3494.343974] RDX: 000000000000000a RSI: 0000000000000000 RDI: ffff8804bd6d4da8 >> [ 3494.343974] RBP: ffff8804d491fef8 R08: ffff8804bf4e84c8 R09: 0000000000000000 >> [ 3494.343974] R10: 00007f53e443c000 R11: 0000000000000001 R12: 00007f53e443c000 >> [ 3494.343974] R13: 000000000000dc51 R14: 006f732e61727478 R15: ffff88047e52b000 >> [ 3494.343974] FS: 00007f53e463f700(0000) GS:ffff880277e00000(0000) knlGS:0000000000000000 >> [ 3494.343974] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >> [ 3494.369895] CR2: 0000000001670fa8 CR3: 0000000283562000 CR4: 00000000000006a0 >> [ 3494.369895] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 >> [ 3494.369895] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 >> [ 3494.380081] Stack: >> [ 3494.380081] ffff8804bf4e80a8 0000000000000014 00007f53e4437000 0000000000000000 >> [ 3494.380081] ffffffff9b976e70 ffff88047e52bbd8 ffff88047e52b000 0000000000000000 >> [ 3494.380081] ffff8804d491ff28 ffffffff95193d84 0000000000000002 ffff8804d491ff58 >> [ 3494.380081] Call Trace: >> [ 3494.380081] task_work_run (kernel/task_work.c:125 (discriminator 1)) >> [ 3494.380081] do_notify_resume (include/linux/tracehook.h:190 arch/x86/kernel/signal.c:758) >> [ 3494.380081] retint_signal (arch/x86/kernel/entry_64.S:918) >> [ 3494.380081] Code: e8 1e e5 01 00 48 89 df 4c 89 e6 e8 a3 2d 13 00 49 89 c6 48 85 c0 0f 84 07 02 00 00 48 c7 45 c8 00 00 00 00 0f 1f 80 00 00 00 00 <49> f7 46 50 00 44 00 00 0f 85 42 01 00 00 49 8b 86 a0 00 00 00 > > Shot in dark, can you test this please? Pagetable teardown can schedule > and I'm wondering if we are trying to add hinting faults to an address > space that is in the process of going away. The TASK_DEAD check is bogus > so replacing it. Mel, I ran today's -next with both of your patches, but the issue still remains: [ 3114.540976] kernel BUG at include/asm-generic/pgtable.h:724! [ 3114.541857] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 3114.543112] Dumping ftrace buffer: [ 3114.544056] (ftrace buffer empty) [ 3114.545000] Modules linked in: [ 3114.545717] CPU: 18 PID: 30217 Comm: trinity-c617 Tainted: G W 3.17.0-rc4-next-20140910-sasha-00032-g6825fb5-dirty #1137 [ 3114.548058] task: ffff880415050000 ti: ffff88076f584000 task.ti: ffff88076f584000 [ 3114.549284] RIP: 0010:[<ffffffff952e527a>] [<ffffffff952e527a>] change_pte_range+0x4ea/0x4f0 [ 3114.550028] RSP: 0000:ffff88076f587d68 EFLAGS: 00010246 [ 3114.550028] RAX: 0000000314625900 RBX: 0000000041218000 RCX: 0000000000000100 [ 3114.550028] RDX: 0000000314625900 RSI: 0000000041218000 RDI: 0000000314625900 [ 3114.550028] RBP: ffff88076f587dc8 R08: ffff8802cf973600 R09: 0000000000b50000 [ 3114.550028] R10: 0000000000032c01 R11: 0000000000000008 R12: ffff8802a81070c0 [ 3114.550028] R13: 8000000000000025 R14: 0000000041343000 R15: ffffc00000000fff [ 3114.550028] FS: 00007fabb91c8700(0000) GS:ffff88025ec00000(0000) knlGS:0000000000000000 [ 3114.550028] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 3114.550028] CR2: 00007fffdb7678e8 CR3: 0000000713935000 CR4: 00000000000006a0 [ 3114.550028] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3114.550028] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000050602 [ 3114.550028] Stack: [ 3114.550028] 0000000000000001 0000000314625900 0000000000000018 ffff8802685f2260 [ 3114.550028] 0000000016840000 ffff8802cf973600 ffff880616840000 0000000041343000 [ 3114.550028] ffff880108805048 0000000041005000 0000000041200000 0000000041343000 [ 3114.550028] Call Trace: [ 3114.550028] [<ffffffff952e5534>] change_protection+0x2b4/0x4e0 [ 3114.550028] [<ffffffff952ff24b>] change_prot_numa+0x1b/0x40 [ 3114.550028] [<ffffffff951adf16>] task_numa_work+0x1f6/0x330 [ 3114.550028] [<ffffffff95193de4>] task_work_run+0xc4/0xf0 [ 3114.550028] [<ffffffff95071477>] do_notify_resume+0x97/0xb0 [ 3114.550028] [<ffffffff9850f06a>] int_signal+0x12/0x17 [ 3114.550028] Code: 66 90 48 8b 7d b8 e8 e6 88 22 03 48 8b 45 b0 e9 6f ff ff ff 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b <0f> 0b 0f 0b 0f 0b 66 66 66 66 90 55 48 89 e5 41 57 49 89 d7 41 [ 3114.550028] RIP [<ffffffff952e527a>] change_pte_range+0x4ea/0x4f0 [ 3114.550028] RSP <ffff88076f587d68> Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-10 16:44 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-10 16:44 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/10/2014 09:40 AM, Mel Gorman wrote: > On Wed, Sep 10, 2014 at 09:12:04AM -0400, Sasha Levin wrote: >> <SNIP, haven't digested the rest> >> >> I've spotted a new trace in overnight fuzzing, it could be related to this issue: >> >> [ 3494.324839] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC >> [ 3494.332153] Dumping ftrace buffer: >> [ 3494.332153] (ftrace buffer empty) >> [ 3494.332153] Modules linked in: >> [ 3494.332153] CPU: 8 PID: 2727 Comm: trinity-c929 Not tainted 3.17.0-rc4-next-20140909-sasha-00032-gc16d47b #1135 >> [ 3494.332153] task: ffff88047e52b000 ti: ffff8804d491c000 task.ti: ffff8804d491c000 >> [ 3494.332153] RIP: task_numa_work (include/linux/mempolicy.h:177 kernel/sched/fair.c:1956) >> [ 3494.332153] RSP: 0000:ffff8804d491feb8 EFLAGS: 00010206 >> [ 3494.332153] RAX: 0000000000000000 RBX: ffff8804bf4e8000 RCX: 000000000000e8e8 >> [ 3494.343974] RDX: 000000000000000a RSI: 0000000000000000 RDI: ffff8804bd6d4da8 >> [ 3494.343974] RBP: ffff8804d491fef8 R08: ffff8804bf4e84c8 R09: 0000000000000000 >> [ 3494.343974] R10: 00007f53e443c000 R11: 0000000000000001 R12: 00007f53e443c000 >> [ 3494.343974] R13: 000000000000dc51 R14: 006f732e61727478 R15: ffff88047e52b000 >> [ 3494.343974] FS: 00007f53e463f700(0000) GS:ffff880277e00000(0000) knlGS:0000000000000000 >> [ 3494.343974] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >> [ 3494.369895] CR2: 0000000001670fa8 CR3: 0000000283562000 CR4: 00000000000006a0 >> [ 3494.369895] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 >> [ 3494.369895] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 >> [ 3494.380081] Stack: >> [ 3494.380081] ffff8804bf4e80a8 0000000000000014 00007f53e4437000 0000000000000000 >> [ 3494.380081] ffffffff9b976e70 ffff88047e52bbd8 ffff88047e52b000 0000000000000000 >> [ 3494.380081] ffff8804d491ff28 ffffffff95193d84 0000000000000002 ffff8804d491ff58 >> [ 3494.380081] Call Trace: >> [ 3494.380081] task_work_run (kernel/task_work.c:125 (discriminator 1)) >> [ 3494.380081] do_notify_resume (include/linux/tracehook.h:190 arch/x86/kernel/signal.c:758) >> [ 3494.380081] retint_signal (arch/x86/kernel/entry_64.S:918) >> [ 3494.380081] Code: e8 1e e5 01 00 48 89 df 4c 89 e6 e8 a3 2d 13 00 49 89 c6 48 85 c0 0f 84 07 02 00 00 48 c7 45 c8 00 00 00 00 0f 1f 80 00 00 00 00 <49> f7 46 50 00 44 00 00 0f 85 42 01 00 00 49 8b 86 a0 00 00 00 > > Shot in dark, can you test this please? Pagetable teardown can schedule > and I'm wondering if we are trying to add hinting faults to an address > space that is in the process of going away. The TASK_DEAD check is bogus > so replacing it. Mel, I ran today's -next with both of your patches, but the issue still remains: [ 3114.540976] kernel BUG at include/asm-generic/pgtable.h:724! [ 3114.541857] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 3114.543112] Dumping ftrace buffer: [ 3114.544056] (ftrace buffer empty) [ 3114.545000] Modules linked in: [ 3114.545717] CPU: 18 PID: 30217 Comm: trinity-c617 Tainted: G W 3.17.0-rc4-next-20140910-sasha-00032-g6825fb5-dirty #1137 [ 3114.548058] task: ffff880415050000 ti: ffff88076f584000 task.ti: ffff88076f584000 [ 3114.549284] RIP: 0010:[<ffffffff952e527a>] [<ffffffff952e527a>] change_pte_range+0x4ea/0x4f0 [ 3114.550028] RSP: 0000:ffff88076f587d68 EFLAGS: 00010246 [ 3114.550028] RAX: 0000000314625900 RBX: 0000000041218000 RCX: 0000000000000100 [ 3114.550028] RDX: 0000000314625900 RSI: 0000000041218000 RDI: 0000000314625900 [ 3114.550028] RBP: ffff88076f587dc8 R08: ffff8802cf973600 R09: 0000000000b50000 [ 3114.550028] R10: 0000000000032c01 R11: 0000000000000008 R12: ffff8802a81070c0 [ 3114.550028] R13: 8000000000000025 R14: 0000000041343000 R15: ffffc00000000fff [ 3114.550028] FS: 00007fabb91c8700(0000) GS:ffff88025ec00000(0000) knlGS:0000000000000000 [ 3114.550028] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 3114.550028] CR2: 00007fffdb7678e8 CR3: 0000000713935000 CR4: 00000000000006a0 [ 3114.550028] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3114.550028] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000050602 [ 3114.550028] Stack: [ 3114.550028] 0000000000000001 0000000314625900 0000000000000018 ffff8802685f2260 [ 3114.550028] 0000000016840000 ffff8802cf973600 ffff880616840000 0000000041343000 [ 3114.550028] ffff880108805048 0000000041005000 0000000041200000 0000000041343000 [ 3114.550028] Call Trace: [ 3114.550028] [<ffffffff952e5534>] change_protection+0x2b4/0x4e0 [ 3114.550028] [<ffffffff952ff24b>] change_prot_numa+0x1b/0x40 [ 3114.550028] [<ffffffff951adf16>] task_numa_work+0x1f6/0x330 [ 3114.550028] [<ffffffff95193de4>] task_work_run+0xc4/0xf0 [ 3114.550028] [<ffffffff95071477>] do_notify_resume+0x97/0xb0 [ 3114.550028] [<ffffffff9850f06a>] int_signal+0x12/0x17 [ 3114.550028] Code: 66 90 48 8b 7d b8 e8 e6 88 22 03 48 8b 45 b0 e9 6f ff ff ff 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b <0f> 0b 0f 0b 0f 0b 66 66 66 66 90 55 48 89 e5 41 57 49 89 d7 41 [ 3114.550028] RIP [<ffffffff952e527a>] change_pte_range+0x4ea/0x4f0 [ 3114.550028] RSP <ffff88076f587d68> 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-10 13:12 ` Sasha Levin @ 2014-09-10 19:09 ` Hugh Dickins -1 siblings, 0 replies; 86+ messages in thread From: Hugh Dickins @ 2014-09-10 19:09 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, Mel Gorman, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Wed, 10 Sep 2014, Sasha Levin wrote: > On 09/09/2014 10:45 PM, Hugh Dickins wrote: > > Sasha, you say you're getting plenty of these now, but I've only seen > > the dump for one of them, on Aug26: please post a few more dumps, so > > that we can look for commonality. > > I wasn't saving older logs for this issue so I only have 2 traces from > tonight. If that's not enough please let me know and I'll try to add > a few more. Thanks, these two are useful, mainly because the register contents most likely to be ptes are in both of these ...900, with no sign of a ...902. So the RW bit I got excited about yesterday is clearly not necessary for the bug (though it's still possible that it was good for implicating page migration, and page migration still play a part in the story). > > And please attach a disassembly of change_protection_range() (noting > > which of the dumps it corresponds to, in case it has changed around): > > "Code" just shows a cluster of ud2s for the unlikely bugs at end of the > > function, we cannot tell at all what should be in the registers by then. > > change_protection_range() got inlined into change_protection(), it applies to > both traces above: Thanks for supplying, but the change in inlining means that change_protection_range() and change_protection() are no longer relevant for these traces, we now need to see change_pte_range() instead, to confirm that what I expect are ptes are indeed ptes. If you can include line numbers (objdump -ld) in the disassembly, so much the better, but should be decipherable without. (Or objdump -Sd for source, but I often find that harder to unscramble, can't say why.) Thanks, Hugh ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-10 19:09 ` Hugh Dickins 0 siblings, 0 replies; 86+ messages in thread From: Hugh Dickins @ 2014-09-10 19:09 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, Mel Gorman, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Wed, 10 Sep 2014, Sasha Levin wrote: > On 09/09/2014 10:45 PM, Hugh Dickins wrote: > > Sasha, you say you're getting plenty of these now, but I've only seen > > the dump for one of them, on Aug26: please post a few more dumps, so > > that we can look for commonality. > > I wasn't saving older logs for this issue so I only have 2 traces from > tonight. If that's not enough please let me know and I'll try to add > a few more. Thanks, these two are useful, mainly because the register contents most likely to be ptes are in both of these ...900, with no sign of a ...902. So the RW bit I got excited about yesterday is clearly not necessary for the bug (though it's still possible that it was good for implicating page migration, and page migration still play a part in the story). > > And please attach a disassembly of change_protection_range() (noting > > which of the dumps it corresponds to, in case it has changed around): > > "Code" just shows a cluster of ud2s for the unlikely bugs at end of the > > function, we cannot tell at all what should be in the registers by then. > > change_protection_range() got inlined into change_protection(), it applies to > both traces above: Thanks for supplying, but the change in inlining means that change_protection_range() and change_protection() are no longer relevant for these traces, we now need to see change_pte_range() instead, to confirm that what I expect are ptes are indeed ptes. If you can include line numbers (objdump -ld) in the disassembly, so much the better, but should be decipherable without. (Or objdump -Sd for source, but I often find that harder to unscramble, can't say why.) Thanks, Hugh -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-10 19:09 ` Hugh Dickins @ 2014-09-10 20:36 ` Sasha Levin -1 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-10 20:36 UTC (permalink / raw) To: Hugh Dickins Cc: Mel Gorman, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/10/2014 03:09 PM, Hugh Dickins wrote: > Thanks for supplying, but the change in inlining means that > change_protection_range() and change_protection() are no longer > relevant for these traces, we now need to see change_pte_range() > instead, to confirm that what I expect are ptes are indeed ptes. > > If you can include line numbers (objdump -ld) in the disassembly, so > much the better, but should be decipherable without. (Or objdump -Sd > for source, but I often find that harder to unscramble, can't say why.) Here it is. Note that the source includes both of Mel's debug patches. For reference, here's one trace of the issue with those patches: [ 3114.540976] kernel BUG at include/asm-generic/pgtable.h:724! [ 3114.541857] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 3114.543112] Dumping ftrace buffer: [ 3114.544056] (ftrace buffer empty) [ 3114.545000] Modules linked in: [ 3114.545717] CPU: 18 PID: 30217 Comm: trinity-c617 Tainted: G W 3.17.0-rc4-next-20140910-sasha-00032-g6825fb5-dirty #1137 [ 3114.548058] task: ffff880415050000 ti: ffff88076f584000 task.ti: ffff88076f584000 [ 3114.549284] RIP: 0010:[<ffffffff952e527a>] [<ffffffff952e527a>] change_pte_range+0x4ea/0x4f0 [ 3114.550028] RSP: 0000:ffff88076f587d68 EFLAGS: 00010246 [ 3114.550028] RAX: 0000000314625900 RBX: 0000000041218000 RCX: 0000000000000100 [ 3114.550028] RDX: 0000000314625900 RSI: 0000000041218000 RDI: 0000000314625900 [ 3114.550028] RBP: ffff88076f587dc8 R08: ffff8802cf973600 R09: 0000000000b50000 [ 3114.550028] R10: 0000000000032c01 R11: 0000000000000008 R12: ffff8802a81070c0 [ 3114.550028] R13: 8000000000000025 R14: 0000000041343000 R15: ffffc00000000fff [ 3114.550028] FS: 00007fabb91c8700(0000) GS:ffff88025ec00000(0000) knlGS:0000000000000000 [ 3114.550028] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 3114.550028] CR2: 00007fffdb7678e8 CR3: 0000000713935000 CR4: 00000000000006a0 [ 3114.550028] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3114.550028] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000050602 [ 3114.550028] Stack: [ 3114.550028] 0000000000000001 0000000314625900 0000000000000018 ffff8802685f2260 [ 3114.550028] 0000000016840000 ffff8802cf973600 ffff880616840000 0000000041343000 [ 3114.550028] ffff880108805048 0000000041005000 0000000041200000 0000000041343000 [ 3114.550028] Call Trace: [ 3114.550028] [<ffffffff952e5534>] change_protection+0x2b4/0x4e0 [ 3114.550028] [<ffffffff952ff24b>] change_prot_numa+0x1b/0x40 [ 3114.550028] [<ffffffff951adf16>] task_numa_work+0x1f6/0x330 [ 3114.550028] [<ffffffff95193de4>] task_work_run+0xc4/0xf0 [ 3114.550028] [<ffffffff95071477>] do_notify_resume+0x97/0xb0 [ 3114.550028] [<ffffffff9850f06a>] int_signal+0x12/0x17 [ 3114.550028] Code: 66 90 48 8b 7d b8 e8 e6 88 22 03 48 8b 45 b0 e9 6f ff ff ff 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b <0f> 0b 0f 0b 0f 0b 66 66 66 66 90 55 48 89 e5 41 57 49 89 d7 41 [ 3114.550028] RIP [<ffffffff952e527a>] change_pte_range+0x4ea/0x4f0 [ 3114.550028] RSP <ffff88076f587d68> And the disassembly: 0000000000000000 <change_pte_range>: change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:70 0: e8 00 00 00 00 callq 5 <change_pte_range+0x5> 1: R_X86_64_PC32 __fentry__-0x4 5: 55 push %rbp 6: 48 89 e5 mov %rsp,%rbp 9: 41 57 push %r15 b: 41 56 push %r14 d: 49 89 ce mov %rcx,%r14 10: 41 55 push %r13 12: 4d 89 c5 mov %r8,%r13 15: 41 54 push %r12 17: 49 89 f4 mov %rsi,%r12 1a: 53 push %rbx 1b: 48 89 d3 mov %rdx,%rbx 1e: 48 83 ec 38 sub $0x38,%rsp /home/sasha/linux-next/mm/mprotect.c:71 22: 48 8b 47 40 mov 0x40(%rdi),%rax /home/sasha/linux-next/mm/mprotect.c:70 26: 48 89 7d c8 mov %rdi,-0x38(%rbp) lock_pte_protection(): /home/sasha/linux-next/mm/mprotect.c:53 2a: 8b 4d 10 mov 0x10(%rbp),%ecx change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:70 2d: 44 89 4d c4 mov %r9d,-0x3c(%rbp) /home/sasha/linux-next/mm/mprotect.c:71 31: 48 89 45 d0 mov %rax,-0x30(%rbp) lock_pte_protection(): /home/sasha/linux-next/mm/mprotect.c:53 35: 85 c9 test %ecx,%ecx 37: 0f 84 6b 03 00 00 je 3a8 <change_pte_range+0x3a8> pmd_to_page(): /home/sasha/linux-next/include/linux/mm.h:1538 3d: 48 89 f7 mov %rsi,%rdi 40: 48 81 e7 00 f0 ff ff and $0xfffffffffffff000,%rdi 47: e8 00 00 00 00 callq 4c <change_pte_range+0x4c> 48: R_X86_64_PC32 __phys_addr-0x4 4c: 48 ba 00 00 00 00 00 movabs $0xffffea0000000000,%rdx 53: ea ff ff 56: 48 c1 e8 0c shr $0xc,%rax spin_lock(): /home/sasha/linux-next/include/linux/spinlock.h:309 5a: 48 89 55 b8 mov %rdx,-0x48(%rbp) 5e: 48 c1 e0 06 shl $0x6,%rax 62: 4c 8b 7c 10 30 mov 0x30(%rax,%rdx,1),%r15 67: 4c 89 ff mov %r15,%rdi 6a: e8 00 00 00 00 callq 6f <change_pte_range+0x6f> 6b: R_X86_64_PC32 _raw_spin_lock-0x4 6f: 49 8b 3c 24 mov (%r12),%rdi pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 73: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 7b <change_pte_range+0x7b> 7a: 00 76: R_X86_64_PC32 pv_mmu_ops+0x10b 7b: 48 8b 55 b8 mov -0x48(%rbp),%rdx 7f: 0f 84 ab 03 00 00 je 430 <change_pte_range+0x430> 85: ff 14 25 00 00 00 00 callq *0x0 88: R_X86_64_32S pv_mmu_ops+0x110 lock_pte_protection(): /home/sasha/linux-next/mm/mprotect.c:57 8c: a8 80 test $0x80,%al 8e: 0f 85 a4 03 00 00 jne 438 <change_pte_range+0x438> 94: 49 8b 3c 24 mov (%r12),%rdi 98: 48 85 ff test %rdi,%rdi 9b: 0f 84 97 03 00 00 je 438 <change_pte_range+0x438> pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 a1: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # a9 <change_pte_range+0xa9> a8: 00 a4: R_X86_64_PC32 pv_mmu_ops+0x10b a9: 0f 84 81 03 00 00 je 430 <change_pte_range+0x430> af: ff 14 25 00 00 00 00 callq *0x0 b2: R_X86_64_32S pv_mmu_ops+0x110 b6: 48 b9 00 f0 ff ff ff movabs $0x3ffffffff000,%rcx bd: 3f 00 00 c0: 48 21 c8 and %rcx,%rax c3: 48 89 c7 mov %rax,%rdi c6: 48 c1 ef 06 shr $0x6,%rdi ca: 48 8b 44 3a 30 mov 0x30(%rdx,%rdi,1),%rax cf: 49 8b 3c 24 mov (%r12),%rdi d3: 48 89 45 b8 mov %rax,-0x48(%rbp) pte_offset_kernel(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:551 d7: 48 89 d8 mov %rbx,%rax da: 48 c1 e8 09 shr $0x9,%rax de: 25 f8 0f 00 00 and $0xff8,%eax pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 e3: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # eb <change_pte_range+0xeb> ea: 00 e6: R_X86_64_PC32 pv_mmu_ops+0x10b pte_offset_kernel(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:551 eb: 48 89 c2 mov %rax,%rdx pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 ee: 0f 84 3c 03 00 00 je 430 <change_pte_range+0x430> f4: ff 14 25 00 00 00 00 callq *0x0 f7: R_X86_64_32S pv_mmu_ops+0x110 spin_lock(): /home/sasha/linux-next/include/linux/spinlock.h:309 fb: 48 8b 7d b8 mov -0x48(%rbp),%rdi pmd_page_vaddr(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 ff: 49 89 c4 mov %rax,%r12 pte_offset_kernel(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:551 102: 48 b8 00 00 00 00 00 movabs $0xffff880000000000,%rax 109: 88 ff ff 10c: 48 01 d0 add %rdx,%rax 10f: 4c 21 e1 and %r12,%rcx 112: 4c 8d 24 08 lea (%rax,%rcx,1),%r12 spin_lock(): /home/sasha/linux-next/include/linux/spinlock.h:309 116: e8 00 00 00 00 callq 11b <change_pte_range+0x11b> 117: R_X86_64_PC32 _raw_spin_lock-0x4 spin_unlock(): /home/sasha/linux-next/include/linux/spinlock.h:349 11b: 4c 89 ff mov %r15,%rdi 11e: e8 00 00 00 00 callq 123 <change_pte_range+0x123> 11f: R_X86_64_PC32 _raw_spin_unlock-0x4 arch_enter_lazy_mmu_mode(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:694 123: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 12b <change_pte_range+0x12b> 12a: 00 126: R_X86_64_PC32 pv_mmu_ops+0x133 12b: 0f 84 a7 03 00 00 je 4d8 <change_pte_range+0x4d8> 131: ff 14 25 00 00 00 00 callq *0x0 134: R_X86_64_32S pv_mmu_ops+0x138 massage_pgprot(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:351 138: 4c 89 e8 mov %r13,%rax change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:74 13b: 48 c7 45 b0 00 00 00 movq $0x0,-0x50(%rbp) 142: 00 pte_present(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:460 143: 49 bf ff 0f 00 00 00 movabs $0xffffc00000000fff,%r15 14a: c0 ff ff massage_pgprot(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:351 14d: 83 e0 01 and $0x1,%eax 150: 48 89 45 a0 mov %rax,-0x60(%rbp) 154: e9 fa 00 00 00 jmpq 253 <change_pte_range+0x253> 159: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:87 160: 8b 55 10 mov 0x10(%rbp),%edx 163: 85 d2 test %edx,%edx 165: 0f 85 85 01 00 00 jne 2f0 <change_pte_range+0x2f0> ptep_modify_prot_start(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:490 16b: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 173 <change_pte_range+0x173> 172: 00 16e: R_X86_64_PC32 pv_mmu_ops+0xd3 173: 0f 84 2f 03 00 00 je 4a8 <change_pte_range+0x4a8> 179: 48 8b 7d d0 mov -0x30(%rbp),%rdi 17d: 48 89 de mov %rbx,%rsi 180: 4c 89 e2 mov %r12,%rdx 183: ff 14 25 00 00 00 00 callq *0x0 186: R_X86_64_32S pv_mmu_ops+0xd8 change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:89 18a: 48 89 c2 mov %rax,%rdx ptep_modify_prot_start(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:490 18d: 48 89 c7 mov %rax,%rdi change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:89 190: 81 e2 01 03 00 00 and $0x301,%edx 196: 48 81 fa 00 02 00 00 cmp $0x200,%rdx 19d: 0f 84 bd 02 00 00 je 460 <change_pte_range+0x460> pte_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:450 1a3: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 1ab <change_pte_range+0x1ab> 1aa: 00 1a6: R_X86_64_PC32 pv_mmu_ops+0xe3 1ab: 0f 84 a7 02 00 00 je 458 <change_pte_range+0x458> 1b1: ff 14 25 00 00 00 00 callq *0x0 1b4: R_X86_64_32S pv_mmu_ops+0xe8 pte_modify(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:377 1b8: 48 be 78 fa ff ff ff movabs $0x3ffffffffa78,%rsi 1bf: 3f 00 00 massage_pgprot(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:352 1c2: 4c 89 ef mov %r13,%rdi 1c5: 48 23 3d 00 00 00 00 and 0x0(%rip),%rdi # 1cc <change_pte_range+0x1cc> 1c8: R_X86_64_PC32 __supported_pte_mask-0x4 pte_modify(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:378 1cc: 48 ba 87 05 00 00 00 movabs $0xffffc00000000587,%rdx 1d3: c0 ff ff /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:377 1d6: 48 21 f0 and %rsi,%rax massage_pgprot(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:352 1d9: 48 83 7d a0 00 cmpq $0x0,-0x60(%rbp) 1de: 49 0f 44 fd cmove %r13,%rdi pte_modify(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:378 1e2: 48 89 f9 mov %rdi,%rcx 1e5: 48 21 d1 and %rdx,%rcx 1e8: 48 09 c1 or %rax,%rcx __pte(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:435 1eb: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 1f3 <change_pte_range+0x1f3> 1f2: 00 1ee: R_X86_64_PC32 pv_mmu_ops+0xeb pte_modify(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:378 1f3: 48 89 cf mov %rcx,%rdi __pte(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:435 1f6: 0f 84 a4 02 00 00 je 4a0 <change_pte_range+0x4a0> 1fc: ff 14 25 00 00 00 00 callq *0x0 1ff: R_X86_64_32S pv_mmu_ops+0xf0 203: 48 89 c1 mov %rax,%rcx change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:96 206: 8b 45 c4 mov -0x3c(%rbp),%eax 209: 85 c0 test %eax,%eax 20b: 74 0e je 21b <change_pte_range+0x21b> pte_set_flags(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:186 (discriminator 1) 20d: 48 89 c8 mov %rcx,%rax 210: 48 83 c8 02 or $0x2,%rax 214: f6 c1 40 test $0x40,%cl 217: 48 0f 45 c8 cmovne %rax,%rcx ptep_modify_prot_commit(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:503 21b: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 223 <change_pte_range+0x223> 222: 00 21e: R_X86_64_PC32 pv_mmu_ops+0xdb 223: 0f 84 b7 02 00 00 je 4e0 <change_pte_range+0x4e0> 229: 48 8b 7d d0 mov -0x30(%rbp),%rdi 22d: 48 89 de mov %rbx,%rsi 230: 4c 89 e2 mov %r12,%rdx 233: ff 14 25 00 00 00 00 callq *0x0 236: R_X86_64_32S pv_mmu_ops+0xe0 change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:128 23a: 48 83 45 b0 01 addq $0x1,-0x50(%rbp) /home/sasha/linux-next/mm/mprotect.c:131 23f: 48 81 c3 00 10 00 00 add $0x1000,%rbx 246: 49 83 c4 08 add $0x8,%r12 24a: 4c 39 f3 cmp %r14,%rbx 24d: 0f 84 5d 02 00 00 je 4b0 <change_pte_range+0x4b0> /home/sasha/linux-next/mm/mprotect.c:82 253: 49 8b 0c 24 mov (%r12),%rcx pte_present(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:460 257: 48 89 c8 mov %rcx,%rax 25a: 4c 21 f8 and %r15,%rax change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:83 25d: a9 01 03 00 00 test $0x301,%eax 262: 0f 85 f8 fe ff ff jne 160 <change_pte_range+0x160> /home/sasha/linux-next/mm/mprotect.c:113 268: a8 40 test $0x40,%al 26a: 75 d3 jne 23f <change_pte_range+0x23f> pte_swp_soft_dirty(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:885 26c: a9 01 01 00 00 test $0x101,%eax 271: 0f 85 71 02 00 00 jne 4e8 <change_pte_range+0x4e8> pte_clear_flags(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:193 277: 48 89 ca mov %rcx,%rdx 27a: 41 89 c0 mov %eax,%r8d 27d: 80 e2 7f and $0x7f,%dl 280: 41 81 e0 80 00 00 00 and $0x80,%r8d 287: 48 0f 45 ca cmovne %rdx,%rcx pte_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:450 28b: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 293 <change_pte_range+0x293> 292: 00 28e: R_X86_64_PC32 pv_mmu_ops+0xe3 293: 0f 84 bf 01 00 00 je 458 <change_pte_range+0x458> 299: 48 89 cf mov %rcx,%rdi 29c: ff 14 25 00 00 00 00 callq *0x0 29f: R_X86_64_32S pv_mmu_ops+0xe8 swp_entry(): /home/sasha/linux-next/include/linux/swapops.h:30 2a3: 48 89 c1 mov %rax,%rcx 2a6: 48 c1 e8 0a shr $0xa,%rax 2aa: 48 d1 e9 shr %rcx 2ad: 83 e1 1f and $0x1f,%ecx 2b0: 48 c1 e1 39 shl $0x39,%rcx 2b4: 48 09 c8 or %rcx,%rax change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:116 2b7: 48 89 c2 mov %rax,%rdx 2ba: 48 c1 ea 39 shr $0x39,%rdx 2be: 48 83 fa 1f cmp $0x1f,%rdx 2c2: 0f 85 77 ff ff ff jne 23f <change_pte_range+0x23f> swp_entry_to_pte(): /home/sasha/linux-next/include/linux/swapops.h:84 2c8: 48 c1 e0 0a shl $0xa,%rax 2cc: 48 89 c1 mov %rax,%rcx 2cf: 0c bc or $0xbc,%al 2d1: 48 83 c9 3c or $0x3c,%rcx 2d5: 45 85 c0 test %r8d,%r8d 2d8: 48 0f 45 c8 cmovne %rax,%rcx set_pte_at(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:524 2dc: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 2e4 <change_pte_range+0x2e4> 2e3: 00 2df: R_X86_64_PC32 pv_mmu_ops+0x9b 2e4: 0f 85 a4 00 00 00 jne 38e <change_pte_range+0x38e> 2ea: 0f 0b ud2 2ec: 0f 1f 40 00 nopl 0x0(%rax) change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:103 2f0: 48 8b 7d c8 mov -0x38(%rbp),%rdi 2f4: 48 89 ca mov %rcx,%rdx 2f7: 48 89 de mov %rbx,%rsi 2fa: 48 89 4d a8 mov %rcx,-0x58(%rbp) 2fe: e8 00 00 00 00 callq 303 <change_pte_range+0x303> 2ff: R_X86_64_PC32 vm_normal_page-0x4 /home/sasha/linux-next/mm/mprotect.c:104 303: 48 85 c0 test %rax,%rax 306: 0f 84 33 ff ff ff je 23f <change_pte_range+0x23f> /home/sasha/linux-next/mm/mprotect.c:104 (discriminator 1) 30c: 48 8b 40 08 mov 0x8(%rax),%rax 310: 83 e0 03 and $0x3,%eax 313: 48 83 f8 03 cmp $0x3,%rax 317: 0f 84 22 ff ff ff je 23f <change_pte_range+0x23f> /home/sasha/linux-next/mm/mprotect.c:105 31d: 48 8b 4d a8 mov -0x58(%rbp),%rcx 321: 81 e1 01 03 00 00 and $0x301,%ecx 327: 48 81 f9 00 02 00 00 cmp $0x200,%rcx 32e: 0f 84 0b ff ff ff je 23f <change_pte_range+0x23f> pte_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:450 334: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 33c <change_pte_range+0x33c> 33b: 00 337: R_X86_64_PC32 pv_mmu_ops+0xe3 ptep_set_numa(): /home/sasha/linux-next/include/asm-generic/pgtable.h:740 33c: 49 8b 3c 24 mov (%r12),%rdi pte_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:450 340: 0f 84 12 01 00 00 je 458 <change_pte_range+0x458> 346: ff 14 25 00 00 00 00 callq *0x0 349: R_X86_64_32S pv_mmu_ops+0xe8 pte_mknuma(): /home/sasha/linux-next/include/asm-generic/pgtable.h:724 34d: a8 01 test $0x1,%al 34f: 0f 84 95 01 00 00 je 4ea <change_pte_range+0x4ea> /home/sasha/linux-next/include/asm-generic/pgtable.h:727 355: f6 c4 01 test $0x1,%ah 358: 0f 85 8e 01 00 00 jne 4ec <change_pte_range+0x4ec> /home/sasha/linux-next/include/asm-generic/pgtable.h:729 35e: 48 83 e0 fe and $0xfffffffffffffffe,%rax /home/sasha/linux-next/include/asm-generic/pgtable.h:730 362: 80 cc 02 or $0x2,%ah __pte(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:435 365: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 36d <change_pte_range+0x36d> 36c: 00 368: R_X86_64_PC32 pv_mmu_ops+0xeb pte_mknuma(): /home/sasha/linux-next/include/asm-generic/pgtable.h:730 36d: 48 89 c7 mov %rax,%rdi __pte(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:435 370: 0f 84 2a 01 00 00 je 4a0 <change_pte_range+0x4a0> 376: ff 14 25 00 00 00 00 callq *0x0 379: R_X86_64_32S pv_mmu_ops+0xf0 set_pte_at(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:524 37d: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 385 <change_pte_range+0x385> 384: 00 380: R_X86_64_PC32 pv_mmu_ops+0x9b pte_mknuma(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:435 385: 48 89 c1 mov %rax,%rcx set_pte_at(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:524 388: 0f 84 5c ff ff ff je 2ea <change_pte_range+0x2ea> 38e: 48 8b 7d d0 mov -0x30(%rbp),%rdi 392: 48 89 de mov %rbx,%rsi 395: 4c 89 e2 mov %r12,%rdx 398: ff 14 25 00 00 00 00 callq *0x0 39b: R_X86_64_32S pv_mmu_ops+0xa0 39f: e9 96 fe ff ff jmpq 23a <change_pte_range+0x23a> 3a4: 0f 1f 40 00 nopl 0x0(%rax) pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 3a8: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 3b0 <change_pte_range+0x3b0> 3af: 00 3ab: R_X86_64_PC32 pv_mmu_ops+0x10b 3b0: 48 8b 3e mov (%rsi),%rdi 3b3: 74 7b je 430 <change_pte_range+0x430> 3b5: ff 14 25 00 00 00 00 callq *0x0 3b8: R_X86_64_32S pv_mmu_ops+0x110 3bc: 48 ba 00 f0 ff ff ff movabs $0x3ffffffff000,%rdx 3c3: 3f 00 00 3c6: 48 21 d0 and %rdx,%rax 3c9: 48 89 c7 mov %rax,%rdi 3cc: 48 b8 00 00 00 00 00 movabs $0xffffea0000000000,%rax 3d3: ea ff ff 3d6: 48 c1 ef 06 shr $0x6,%rdi 3da: 48 8b 44 07 30 mov 0x30(%rdi,%rax,1),%rax 3df: 48 8b 3e mov (%rsi),%rdi 3e2: 48 89 45 b8 mov %rax,-0x48(%rbp) pte_offset_kernel(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:551 3e6: 48 89 d8 mov %rbx,%rax 3e9: 48 c1 e8 09 shr $0x9,%rax 3ed: 25 f8 0f 00 00 and $0xff8,%eax pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 3f2: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 3fa <change_pte_range+0x3fa> 3f9: 00 3f5: R_X86_64_PC32 pv_mmu_ops+0x10b pte_offset_kernel(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:551 3fa: 48 89 c1 mov %rax,%rcx pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 3fd: 74 31 je 430 <change_pte_range+0x430> 3ff: ff 14 25 00 00 00 00 callq *0x0 402: R_X86_64_32S pv_mmu_ops+0x110 spin_lock(): /home/sasha/linux-next/include/linux/spinlock.h:309 406: 48 8b 7d b8 mov -0x48(%rbp),%rdi pmd_page_vaddr(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 40a: 49 89 c4 mov %rax,%r12 pte_offset_kernel(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:551 40d: 48 b8 00 00 00 00 00 movabs $0xffff880000000000,%rax 414: 88 ff ff 417: 48 01 c8 add %rcx,%rax 41a: 4c 21 e2 and %r12,%rdx 41d: 4c 8d 24 10 lea (%rax,%rdx,1),%r12 spin_lock(): /home/sasha/linux-next/include/linux/spinlock.h:309 421: e8 00 00 00 00 callq 426 <change_pte_range+0x426> 422: R_X86_64_PC32 _raw_spin_lock-0x4 426: e9 f8 fc ff ff jmpq 123 <change_pte_range+0x123> 42b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 430: 0f 0b ud2 432: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) spin_unlock(): /home/sasha/linux-next/include/linux/spinlock.h:349 438: 4c 89 ff mov %r15,%rdi 43b: e8 00 00 00 00 callq 440 <change_pte_range+0x440> 43c: R_X86_64_PC32 _raw_spin_unlock-0x4 change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:78 440: 31 c0 xor %eax,%eax /home/sasha/linux-next/mm/mprotect.c:136 442: 48 83 c4 38 add $0x38,%rsp 446: 5b pop %rbx 447: 41 5c pop %r12 449: 41 5d pop %r13 44b: 41 5e pop %r14 44d: 41 5f pop %r15 44f: 5d pop %rbp 450: c3 retq 451: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) pte_to_swp_entry(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:450 458: 0f 0b ud2 45a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) pte_val(): 460: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 468 <change_pte_range+0x468> 467: 00 463: R_X86_64_PC32 pv_mmu_ops+0xe3 468: 74 ee je 458 <change_pte_range+0x458> 46a: 48 89 c7 mov %rax,%rdi 46d: ff 14 25 00 00 00 00 callq *0x0 470: R_X86_64_32S pv_mmu_ops+0xe8 pte_mknonnuma(): /home/sasha/linux-next/include/asm-generic/pgtable.h:701 474: 80 e4 fd and $0xfd,%ah /home/sasha/linux-next/include/asm-generic/pgtable.h:702 477: 48 83 c8 21 or $0x21,%rax __pte(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:435 47b: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 483 <change_pte_range+0x483> 482: 00 47e: R_X86_64_PC32 pv_mmu_ops+0xeb pte_mknonnuma(): /home/sasha/linux-next/include/asm-generic/pgtable.h:702 483: 48 89 c7 mov %rax,%rdi __pte(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:435 486: 74 18 je 4a0 <change_pte_range+0x4a0> 488: ff 14 25 00 00 00 00 callq *0x0 48b: R_X86_64_32S pv_mmu_ops+0xf0 48f: 48 89 c7 mov %rax,%rdi 492: e9 0c fd ff ff jmpq 1a3 <change_pte_range+0x1a3> 497: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1) 49e: 00 00 4a0: 0f 0b ud2 4a2: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) ptep_modify_prot_start(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:490 4a8: 0f 0b ud2 4aa: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) arch_leave_lazy_mmu_mode(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:699 4b0: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 4b8 <change_pte_range+0x4b8> 4b7: 00 4b3: R_X86_64_PC32 pv_mmu_ops+0x13b 4b8: 74 34 je 4ee <change_pte_range+0x4ee> 4ba: ff 14 25 00 00 00 00 callq *0x0 4bd: R_X86_64_32S pv_mmu_ops+0x140 spin_unlock(): /home/sasha/linux-next/include/linux/spinlock.h:349 4c1: 48 8b 7d b8 mov -0x48(%rbp),%rdi 4c5: e8 00 00 00 00 callq 4ca <change_pte_range+0x4ca> 4c6: R_X86_64_PC32 _raw_spin_unlock-0x4 change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:135 4ca: 48 8b 45 b0 mov -0x50(%rbp),%rax 4ce: e9 6f ff ff ff jmpq 442 <change_pte_range+0x442> 4d3: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) arch_enter_lazy_mmu_mode(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:694 4d8: 0f 0b ud2 4da: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) ptep_modify_prot_commit(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:503 4e0: 0f 0b ud2 4e2: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) pte_to_swp_entry(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:885 4e8: 0f 0b ud2 ptep_set_numa(): /home/sasha/linux-next/include/asm-generic/pgtable.h:724 4ea: 0f 0b ud2 /home/sasha/linux-next/include/asm-generic/pgtable.h:727 4ec: 0f 0b ud2 arch_leave_lazy_mmu_mode(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:699 4ee: 0f 0b ud2 Thanks, Sasha ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-10 20:36 ` Sasha Levin 0 siblings, 0 replies; 86+ messages in thread From: Sasha Levin @ 2014-09-10 20:36 UTC (permalink / raw) To: Hugh Dickins Cc: Mel Gorman, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On 09/10/2014 03:09 PM, Hugh Dickins wrote: > Thanks for supplying, but the change in inlining means that > change_protection_range() and change_protection() are no longer > relevant for these traces, we now need to see change_pte_range() > instead, to confirm that what I expect are ptes are indeed ptes. > > If you can include line numbers (objdump -ld) in the disassembly, so > much the better, but should be decipherable without. (Or objdump -Sd > for source, but I often find that harder to unscramble, can't say why.) Here it is. Note that the source includes both of Mel's debug patches. For reference, here's one trace of the issue with those patches: [ 3114.540976] kernel BUG at include/asm-generic/pgtable.h:724! [ 3114.541857] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 3114.543112] Dumping ftrace buffer: [ 3114.544056] (ftrace buffer empty) [ 3114.545000] Modules linked in: [ 3114.545717] CPU: 18 PID: 30217 Comm: trinity-c617 Tainted: G W 3.17.0-rc4-next-20140910-sasha-00032-g6825fb5-dirty #1137 [ 3114.548058] task: ffff880415050000 ti: ffff88076f584000 task.ti: ffff88076f584000 [ 3114.549284] RIP: 0010:[<ffffffff952e527a>] [<ffffffff952e527a>] change_pte_range+0x4ea/0x4f0 [ 3114.550028] RSP: 0000:ffff88076f587d68 EFLAGS: 00010246 [ 3114.550028] RAX: 0000000314625900 RBX: 0000000041218000 RCX: 0000000000000100 [ 3114.550028] RDX: 0000000314625900 RSI: 0000000041218000 RDI: 0000000314625900 [ 3114.550028] RBP: ffff88076f587dc8 R08: ffff8802cf973600 R09: 0000000000b50000 [ 3114.550028] R10: 0000000000032c01 R11: 0000000000000008 R12: ffff8802a81070c0 [ 3114.550028] R13: 8000000000000025 R14: 0000000041343000 R15: ffffc00000000fff [ 3114.550028] FS: 00007fabb91c8700(0000) GS:ffff88025ec00000(0000) knlGS:0000000000000000 [ 3114.550028] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 3114.550028] CR2: 00007fffdb7678e8 CR3: 0000000713935000 CR4: 00000000000006a0 [ 3114.550028] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3114.550028] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000050602 [ 3114.550028] Stack: [ 3114.550028] 0000000000000001 0000000314625900 0000000000000018 ffff8802685f2260 [ 3114.550028] 0000000016840000 ffff8802cf973600 ffff880616840000 0000000041343000 [ 3114.550028] ffff880108805048 0000000041005000 0000000041200000 0000000041343000 [ 3114.550028] Call Trace: [ 3114.550028] [<ffffffff952e5534>] change_protection+0x2b4/0x4e0 [ 3114.550028] [<ffffffff952ff24b>] change_prot_numa+0x1b/0x40 [ 3114.550028] [<ffffffff951adf16>] task_numa_work+0x1f6/0x330 [ 3114.550028] [<ffffffff95193de4>] task_work_run+0xc4/0xf0 [ 3114.550028] [<ffffffff95071477>] do_notify_resume+0x97/0xb0 [ 3114.550028] [<ffffffff9850f06a>] int_signal+0x12/0x17 [ 3114.550028] Code: 66 90 48 8b 7d b8 e8 e6 88 22 03 48 8b 45 b0 e9 6f ff ff ff 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b <0f> 0b 0f 0b 0f 0b 66 66 66 66 90 55 48 89 e5 41 57 49 89 d7 41 [ 3114.550028] RIP [<ffffffff952e527a>] change_pte_range+0x4ea/0x4f0 [ 3114.550028] RSP <ffff88076f587d68> And the disassembly: 0000000000000000 <change_pte_range>: change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:70 0: e8 00 00 00 00 callq 5 <change_pte_range+0x5> 1: R_X86_64_PC32 __fentry__-0x4 5: 55 push %rbp 6: 48 89 e5 mov %rsp,%rbp 9: 41 57 push %r15 b: 41 56 push %r14 d: 49 89 ce mov %rcx,%r14 10: 41 55 push %r13 12: 4d 89 c5 mov %r8,%r13 15: 41 54 push %r12 17: 49 89 f4 mov %rsi,%r12 1a: 53 push %rbx 1b: 48 89 d3 mov %rdx,%rbx 1e: 48 83 ec 38 sub $0x38,%rsp /home/sasha/linux-next/mm/mprotect.c:71 22: 48 8b 47 40 mov 0x40(%rdi),%rax /home/sasha/linux-next/mm/mprotect.c:70 26: 48 89 7d c8 mov %rdi,-0x38(%rbp) lock_pte_protection(): /home/sasha/linux-next/mm/mprotect.c:53 2a: 8b 4d 10 mov 0x10(%rbp),%ecx change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:70 2d: 44 89 4d c4 mov %r9d,-0x3c(%rbp) /home/sasha/linux-next/mm/mprotect.c:71 31: 48 89 45 d0 mov %rax,-0x30(%rbp) lock_pte_protection(): /home/sasha/linux-next/mm/mprotect.c:53 35: 85 c9 test %ecx,%ecx 37: 0f 84 6b 03 00 00 je 3a8 <change_pte_range+0x3a8> pmd_to_page(): /home/sasha/linux-next/include/linux/mm.h:1538 3d: 48 89 f7 mov %rsi,%rdi 40: 48 81 e7 00 f0 ff ff and $0xfffffffffffff000,%rdi 47: e8 00 00 00 00 callq 4c <change_pte_range+0x4c> 48: R_X86_64_PC32 __phys_addr-0x4 4c: 48 ba 00 00 00 00 00 movabs $0xffffea0000000000,%rdx 53: ea ff ff 56: 48 c1 e8 0c shr $0xc,%rax spin_lock(): /home/sasha/linux-next/include/linux/spinlock.h:309 5a: 48 89 55 b8 mov %rdx,-0x48(%rbp) 5e: 48 c1 e0 06 shl $0x6,%rax 62: 4c 8b 7c 10 30 mov 0x30(%rax,%rdx,1),%r15 67: 4c 89 ff mov %r15,%rdi 6a: e8 00 00 00 00 callq 6f <change_pte_range+0x6f> 6b: R_X86_64_PC32 _raw_spin_lock-0x4 6f: 49 8b 3c 24 mov (%r12),%rdi pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 73: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 7b <change_pte_range+0x7b> 7a: 00 76: R_X86_64_PC32 pv_mmu_ops+0x10b 7b: 48 8b 55 b8 mov -0x48(%rbp),%rdx 7f: 0f 84 ab 03 00 00 je 430 <change_pte_range+0x430> 85: ff 14 25 00 00 00 00 callq *0x0 88: R_X86_64_32S pv_mmu_ops+0x110 lock_pte_protection(): /home/sasha/linux-next/mm/mprotect.c:57 8c: a8 80 test $0x80,%al 8e: 0f 85 a4 03 00 00 jne 438 <change_pte_range+0x438> 94: 49 8b 3c 24 mov (%r12),%rdi 98: 48 85 ff test %rdi,%rdi 9b: 0f 84 97 03 00 00 je 438 <change_pte_range+0x438> pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 a1: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # a9 <change_pte_range+0xa9> a8: 00 a4: R_X86_64_PC32 pv_mmu_ops+0x10b a9: 0f 84 81 03 00 00 je 430 <change_pte_range+0x430> af: ff 14 25 00 00 00 00 callq *0x0 b2: R_X86_64_32S pv_mmu_ops+0x110 b6: 48 b9 00 f0 ff ff ff movabs $0x3ffffffff000,%rcx bd: 3f 00 00 c0: 48 21 c8 and %rcx,%rax c3: 48 89 c7 mov %rax,%rdi c6: 48 c1 ef 06 shr $0x6,%rdi ca: 48 8b 44 3a 30 mov 0x30(%rdx,%rdi,1),%rax cf: 49 8b 3c 24 mov (%r12),%rdi d3: 48 89 45 b8 mov %rax,-0x48(%rbp) pte_offset_kernel(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:551 d7: 48 89 d8 mov %rbx,%rax da: 48 c1 e8 09 shr $0x9,%rax de: 25 f8 0f 00 00 and $0xff8,%eax pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 e3: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # eb <change_pte_range+0xeb> ea: 00 e6: R_X86_64_PC32 pv_mmu_ops+0x10b pte_offset_kernel(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:551 eb: 48 89 c2 mov %rax,%rdx pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 ee: 0f 84 3c 03 00 00 je 430 <change_pte_range+0x430> f4: ff 14 25 00 00 00 00 callq *0x0 f7: R_X86_64_32S pv_mmu_ops+0x110 spin_lock(): /home/sasha/linux-next/include/linux/spinlock.h:309 fb: 48 8b 7d b8 mov -0x48(%rbp),%rdi pmd_page_vaddr(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 ff: 49 89 c4 mov %rax,%r12 pte_offset_kernel(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:551 102: 48 b8 00 00 00 00 00 movabs $0xffff880000000000,%rax 109: 88 ff ff 10c: 48 01 d0 add %rdx,%rax 10f: 4c 21 e1 and %r12,%rcx 112: 4c 8d 24 08 lea (%rax,%rcx,1),%r12 spin_lock(): /home/sasha/linux-next/include/linux/spinlock.h:309 116: e8 00 00 00 00 callq 11b <change_pte_range+0x11b> 117: R_X86_64_PC32 _raw_spin_lock-0x4 spin_unlock(): /home/sasha/linux-next/include/linux/spinlock.h:349 11b: 4c 89 ff mov %r15,%rdi 11e: e8 00 00 00 00 callq 123 <change_pte_range+0x123> 11f: R_X86_64_PC32 _raw_spin_unlock-0x4 arch_enter_lazy_mmu_mode(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:694 123: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 12b <change_pte_range+0x12b> 12a: 00 126: R_X86_64_PC32 pv_mmu_ops+0x133 12b: 0f 84 a7 03 00 00 je 4d8 <change_pte_range+0x4d8> 131: ff 14 25 00 00 00 00 callq *0x0 134: R_X86_64_32S pv_mmu_ops+0x138 massage_pgprot(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:351 138: 4c 89 e8 mov %r13,%rax change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:74 13b: 48 c7 45 b0 00 00 00 movq $0x0,-0x50(%rbp) 142: 00 pte_present(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:460 143: 49 bf ff 0f 00 00 00 movabs $0xffffc00000000fff,%r15 14a: c0 ff ff massage_pgprot(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:351 14d: 83 e0 01 and $0x1,%eax 150: 48 89 45 a0 mov %rax,-0x60(%rbp) 154: e9 fa 00 00 00 jmpq 253 <change_pte_range+0x253> 159: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:87 160: 8b 55 10 mov 0x10(%rbp),%edx 163: 85 d2 test %edx,%edx 165: 0f 85 85 01 00 00 jne 2f0 <change_pte_range+0x2f0> ptep_modify_prot_start(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:490 16b: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 173 <change_pte_range+0x173> 172: 00 16e: R_X86_64_PC32 pv_mmu_ops+0xd3 173: 0f 84 2f 03 00 00 je 4a8 <change_pte_range+0x4a8> 179: 48 8b 7d d0 mov -0x30(%rbp),%rdi 17d: 48 89 de mov %rbx,%rsi 180: 4c 89 e2 mov %r12,%rdx 183: ff 14 25 00 00 00 00 callq *0x0 186: R_X86_64_32S pv_mmu_ops+0xd8 change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:89 18a: 48 89 c2 mov %rax,%rdx ptep_modify_prot_start(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:490 18d: 48 89 c7 mov %rax,%rdi change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:89 190: 81 e2 01 03 00 00 and $0x301,%edx 196: 48 81 fa 00 02 00 00 cmp $0x200,%rdx 19d: 0f 84 bd 02 00 00 je 460 <change_pte_range+0x460> pte_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:450 1a3: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 1ab <change_pte_range+0x1ab> 1aa: 00 1a6: R_X86_64_PC32 pv_mmu_ops+0xe3 1ab: 0f 84 a7 02 00 00 je 458 <change_pte_range+0x458> 1b1: ff 14 25 00 00 00 00 callq *0x0 1b4: R_X86_64_32S pv_mmu_ops+0xe8 pte_modify(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:377 1b8: 48 be 78 fa ff ff ff movabs $0x3ffffffffa78,%rsi 1bf: 3f 00 00 massage_pgprot(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:352 1c2: 4c 89 ef mov %r13,%rdi 1c5: 48 23 3d 00 00 00 00 and 0x0(%rip),%rdi # 1cc <change_pte_range+0x1cc> 1c8: R_X86_64_PC32 __supported_pte_mask-0x4 pte_modify(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:378 1cc: 48 ba 87 05 00 00 00 movabs $0xffffc00000000587,%rdx 1d3: c0 ff ff /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:377 1d6: 48 21 f0 and %rsi,%rax massage_pgprot(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:352 1d9: 48 83 7d a0 00 cmpq $0x0,-0x60(%rbp) 1de: 49 0f 44 fd cmove %r13,%rdi pte_modify(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:378 1e2: 48 89 f9 mov %rdi,%rcx 1e5: 48 21 d1 and %rdx,%rcx 1e8: 48 09 c1 or %rax,%rcx __pte(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:435 1eb: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 1f3 <change_pte_range+0x1f3> 1f2: 00 1ee: R_X86_64_PC32 pv_mmu_ops+0xeb pte_modify(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:378 1f3: 48 89 cf mov %rcx,%rdi __pte(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:435 1f6: 0f 84 a4 02 00 00 je 4a0 <change_pte_range+0x4a0> 1fc: ff 14 25 00 00 00 00 callq *0x0 1ff: R_X86_64_32S pv_mmu_ops+0xf0 203: 48 89 c1 mov %rax,%rcx change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:96 206: 8b 45 c4 mov -0x3c(%rbp),%eax 209: 85 c0 test %eax,%eax 20b: 74 0e je 21b <change_pte_range+0x21b> pte_set_flags(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:186 (discriminator 1) 20d: 48 89 c8 mov %rcx,%rax 210: 48 83 c8 02 or $0x2,%rax 214: f6 c1 40 test $0x40,%cl 217: 48 0f 45 c8 cmovne %rax,%rcx ptep_modify_prot_commit(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:503 21b: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 223 <change_pte_range+0x223> 222: 00 21e: R_X86_64_PC32 pv_mmu_ops+0xdb 223: 0f 84 b7 02 00 00 je 4e0 <change_pte_range+0x4e0> 229: 48 8b 7d d0 mov -0x30(%rbp),%rdi 22d: 48 89 de mov %rbx,%rsi 230: 4c 89 e2 mov %r12,%rdx 233: ff 14 25 00 00 00 00 callq *0x0 236: R_X86_64_32S pv_mmu_ops+0xe0 change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:128 23a: 48 83 45 b0 01 addq $0x1,-0x50(%rbp) /home/sasha/linux-next/mm/mprotect.c:131 23f: 48 81 c3 00 10 00 00 add $0x1000,%rbx 246: 49 83 c4 08 add $0x8,%r12 24a: 4c 39 f3 cmp %r14,%rbx 24d: 0f 84 5d 02 00 00 je 4b0 <change_pte_range+0x4b0> /home/sasha/linux-next/mm/mprotect.c:82 253: 49 8b 0c 24 mov (%r12),%rcx pte_present(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:460 257: 48 89 c8 mov %rcx,%rax 25a: 4c 21 f8 and %r15,%rax change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:83 25d: a9 01 03 00 00 test $0x301,%eax 262: 0f 85 f8 fe ff ff jne 160 <change_pte_range+0x160> /home/sasha/linux-next/mm/mprotect.c:113 268: a8 40 test $0x40,%al 26a: 75 d3 jne 23f <change_pte_range+0x23f> pte_swp_soft_dirty(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:885 26c: a9 01 01 00 00 test $0x101,%eax 271: 0f 85 71 02 00 00 jne 4e8 <change_pte_range+0x4e8> pte_clear_flags(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:193 277: 48 89 ca mov %rcx,%rdx 27a: 41 89 c0 mov %eax,%r8d 27d: 80 e2 7f and $0x7f,%dl 280: 41 81 e0 80 00 00 00 and $0x80,%r8d 287: 48 0f 45 ca cmovne %rdx,%rcx pte_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:450 28b: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 293 <change_pte_range+0x293> 292: 00 28e: R_X86_64_PC32 pv_mmu_ops+0xe3 293: 0f 84 bf 01 00 00 je 458 <change_pte_range+0x458> 299: 48 89 cf mov %rcx,%rdi 29c: ff 14 25 00 00 00 00 callq *0x0 29f: R_X86_64_32S pv_mmu_ops+0xe8 swp_entry(): /home/sasha/linux-next/include/linux/swapops.h:30 2a3: 48 89 c1 mov %rax,%rcx 2a6: 48 c1 e8 0a shr $0xa,%rax 2aa: 48 d1 e9 shr %rcx 2ad: 83 e1 1f and $0x1f,%ecx 2b0: 48 c1 e1 39 shl $0x39,%rcx 2b4: 48 09 c8 or %rcx,%rax change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:116 2b7: 48 89 c2 mov %rax,%rdx 2ba: 48 c1 ea 39 shr $0x39,%rdx 2be: 48 83 fa 1f cmp $0x1f,%rdx 2c2: 0f 85 77 ff ff ff jne 23f <change_pte_range+0x23f> swp_entry_to_pte(): /home/sasha/linux-next/include/linux/swapops.h:84 2c8: 48 c1 e0 0a shl $0xa,%rax 2cc: 48 89 c1 mov %rax,%rcx 2cf: 0c bc or $0xbc,%al 2d1: 48 83 c9 3c or $0x3c,%rcx 2d5: 45 85 c0 test %r8d,%r8d 2d8: 48 0f 45 c8 cmovne %rax,%rcx set_pte_at(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:524 2dc: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 2e4 <change_pte_range+0x2e4> 2e3: 00 2df: R_X86_64_PC32 pv_mmu_ops+0x9b 2e4: 0f 85 a4 00 00 00 jne 38e <change_pte_range+0x38e> 2ea: 0f 0b ud2 2ec: 0f 1f 40 00 nopl 0x0(%rax) change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:103 2f0: 48 8b 7d c8 mov -0x38(%rbp),%rdi 2f4: 48 89 ca mov %rcx,%rdx 2f7: 48 89 de mov %rbx,%rsi 2fa: 48 89 4d a8 mov %rcx,-0x58(%rbp) 2fe: e8 00 00 00 00 callq 303 <change_pte_range+0x303> 2ff: R_X86_64_PC32 vm_normal_page-0x4 /home/sasha/linux-next/mm/mprotect.c:104 303: 48 85 c0 test %rax,%rax 306: 0f 84 33 ff ff ff je 23f <change_pte_range+0x23f> /home/sasha/linux-next/mm/mprotect.c:104 (discriminator 1) 30c: 48 8b 40 08 mov 0x8(%rax),%rax 310: 83 e0 03 and $0x3,%eax 313: 48 83 f8 03 cmp $0x3,%rax 317: 0f 84 22 ff ff ff je 23f <change_pte_range+0x23f> /home/sasha/linux-next/mm/mprotect.c:105 31d: 48 8b 4d a8 mov -0x58(%rbp),%rcx 321: 81 e1 01 03 00 00 and $0x301,%ecx 327: 48 81 f9 00 02 00 00 cmp $0x200,%rcx 32e: 0f 84 0b ff ff ff je 23f <change_pte_range+0x23f> pte_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:450 334: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 33c <change_pte_range+0x33c> 33b: 00 337: R_X86_64_PC32 pv_mmu_ops+0xe3 ptep_set_numa(): /home/sasha/linux-next/include/asm-generic/pgtable.h:740 33c: 49 8b 3c 24 mov (%r12),%rdi pte_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:450 340: 0f 84 12 01 00 00 je 458 <change_pte_range+0x458> 346: ff 14 25 00 00 00 00 callq *0x0 349: R_X86_64_32S pv_mmu_ops+0xe8 pte_mknuma(): /home/sasha/linux-next/include/asm-generic/pgtable.h:724 34d: a8 01 test $0x1,%al 34f: 0f 84 95 01 00 00 je 4ea <change_pte_range+0x4ea> /home/sasha/linux-next/include/asm-generic/pgtable.h:727 355: f6 c4 01 test $0x1,%ah 358: 0f 85 8e 01 00 00 jne 4ec <change_pte_range+0x4ec> /home/sasha/linux-next/include/asm-generic/pgtable.h:729 35e: 48 83 e0 fe and $0xfffffffffffffffe,%rax /home/sasha/linux-next/include/asm-generic/pgtable.h:730 362: 80 cc 02 or $0x2,%ah __pte(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:435 365: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 36d <change_pte_range+0x36d> 36c: 00 368: R_X86_64_PC32 pv_mmu_ops+0xeb pte_mknuma(): /home/sasha/linux-next/include/asm-generic/pgtable.h:730 36d: 48 89 c7 mov %rax,%rdi __pte(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:435 370: 0f 84 2a 01 00 00 je 4a0 <change_pte_range+0x4a0> 376: ff 14 25 00 00 00 00 callq *0x0 379: R_X86_64_32S pv_mmu_ops+0xf0 set_pte_at(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:524 37d: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 385 <change_pte_range+0x385> 384: 00 380: R_X86_64_PC32 pv_mmu_ops+0x9b pte_mknuma(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:435 385: 48 89 c1 mov %rax,%rcx set_pte_at(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:524 388: 0f 84 5c ff ff ff je 2ea <change_pte_range+0x2ea> 38e: 48 8b 7d d0 mov -0x30(%rbp),%rdi 392: 48 89 de mov %rbx,%rsi 395: 4c 89 e2 mov %r12,%rdx 398: ff 14 25 00 00 00 00 callq *0x0 39b: R_X86_64_32S pv_mmu_ops+0xa0 39f: e9 96 fe ff ff jmpq 23a <change_pte_range+0x23a> 3a4: 0f 1f 40 00 nopl 0x0(%rax) pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 3a8: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 3b0 <change_pte_range+0x3b0> 3af: 00 3ab: R_X86_64_PC32 pv_mmu_ops+0x10b 3b0: 48 8b 3e mov (%rsi),%rdi 3b3: 74 7b je 430 <change_pte_range+0x430> 3b5: ff 14 25 00 00 00 00 callq *0x0 3b8: R_X86_64_32S pv_mmu_ops+0x110 3bc: 48 ba 00 f0 ff ff ff movabs $0x3ffffffff000,%rdx 3c3: 3f 00 00 3c6: 48 21 d0 and %rdx,%rax 3c9: 48 89 c7 mov %rax,%rdi 3cc: 48 b8 00 00 00 00 00 movabs $0xffffea0000000000,%rax 3d3: ea ff ff 3d6: 48 c1 ef 06 shr $0x6,%rdi 3da: 48 8b 44 07 30 mov 0x30(%rdi,%rax,1),%rax 3df: 48 8b 3e mov (%rsi),%rdi 3e2: 48 89 45 b8 mov %rax,-0x48(%rbp) pte_offset_kernel(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:551 3e6: 48 89 d8 mov %rbx,%rax 3e9: 48 c1 e8 09 shr $0x9,%rax 3ed: 25 f8 0f 00 00 and $0xff8,%eax pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 3f2: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 3fa <change_pte_range+0x3fa> 3f9: 00 3f5: R_X86_64_PC32 pv_mmu_ops+0x10b pte_offset_kernel(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:551 3fa: 48 89 c1 mov %rax,%rcx pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 3fd: 74 31 je 430 <change_pte_range+0x430> 3ff: ff 14 25 00 00 00 00 callq *0x0 402: R_X86_64_32S pv_mmu_ops+0x110 spin_lock(): /home/sasha/linux-next/include/linux/spinlock.h:309 406: 48 8b 7d b8 mov -0x48(%rbp),%rdi pmd_page_vaddr(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 40a: 49 89 c4 mov %rax,%r12 pte_offset_kernel(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:551 40d: 48 b8 00 00 00 00 00 movabs $0xffff880000000000,%rax 414: 88 ff ff 417: 48 01 c8 add %rcx,%rax 41a: 4c 21 e2 and %r12,%rdx 41d: 4c 8d 24 10 lea (%rax,%rdx,1),%r12 spin_lock(): /home/sasha/linux-next/include/linux/spinlock.h:309 421: e8 00 00 00 00 callq 426 <change_pte_range+0x426> 422: R_X86_64_PC32 _raw_spin_lock-0x4 426: e9 f8 fc ff ff jmpq 123 <change_pte_range+0x123> 42b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) pmd_val(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:571 430: 0f 0b ud2 432: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) spin_unlock(): /home/sasha/linux-next/include/linux/spinlock.h:349 438: 4c 89 ff mov %r15,%rdi 43b: e8 00 00 00 00 callq 440 <change_pte_range+0x440> 43c: R_X86_64_PC32 _raw_spin_unlock-0x4 change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:78 440: 31 c0 xor %eax,%eax /home/sasha/linux-next/mm/mprotect.c:136 442: 48 83 c4 38 add $0x38,%rsp 446: 5b pop %rbx 447: 41 5c pop %r12 449: 41 5d pop %r13 44b: 41 5e pop %r14 44d: 41 5f pop %r15 44f: 5d pop %rbp 450: c3 retq 451: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) pte_to_swp_entry(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:450 458: 0f 0b ud2 45a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) pte_val(): 460: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 468 <change_pte_range+0x468> 467: 00 463: R_X86_64_PC32 pv_mmu_ops+0xe3 468: 74 ee je 458 <change_pte_range+0x458> 46a: 48 89 c7 mov %rax,%rdi 46d: ff 14 25 00 00 00 00 callq *0x0 470: R_X86_64_32S pv_mmu_ops+0xe8 pte_mknonnuma(): /home/sasha/linux-next/include/asm-generic/pgtable.h:701 474: 80 e4 fd and $0xfd,%ah /home/sasha/linux-next/include/asm-generic/pgtable.h:702 477: 48 83 c8 21 or $0x21,%rax __pte(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:435 47b: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 483 <change_pte_range+0x483> 482: 00 47e: R_X86_64_PC32 pv_mmu_ops+0xeb pte_mknonnuma(): /home/sasha/linux-next/include/asm-generic/pgtable.h:702 483: 48 89 c7 mov %rax,%rdi __pte(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:435 486: 74 18 je 4a0 <change_pte_range+0x4a0> 488: ff 14 25 00 00 00 00 callq *0x0 48b: R_X86_64_32S pv_mmu_ops+0xf0 48f: 48 89 c7 mov %rax,%rdi 492: e9 0c fd ff ff jmpq 1a3 <change_pte_range+0x1a3> 497: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1) 49e: 00 00 4a0: 0f 0b ud2 4a2: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) ptep_modify_prot_start(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:490 4a8: 0f 0b ud2 4aa: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) arch_leave_lazy_mmu_mode(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:699 4b0: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 4b8 <change_pte_range+0x4b8> 4b7: 00 4b3: R_X86_64_PC32 pv_mmu_ops+0x13b 4b8: 74 34 je 4ee <change_pte_range+0x4ee> 4ba: ff 14 25 00 00 00 00 callq *0x0 4bd: R_X86_64_32S pv_mmu_ops+0x140 spin_unlock(): /home/sasha/linux-next/include/linux/spinlock.h:349 4c1: 48 8b 7d b8 mov -0x48(%rbp),%rdi 4c5: e8 00 00 00 00 callq 4ca <change_pte_range+0x4ca> 4c6: R_X86_64_PC32 _raw_spin_unlock-0x4 change_pte_range(): /home/sasha/linux-next/mm/mprotect.c:135 4ca: 48 8b 45 b0 mov -0x50(%rbp),%rax 4ce: e9 6f ff ff ff jmpq 442 <change_pte_range+0x442> 4d3: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) arch_enter_lazy_mmu_mode(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:694 4d8: 0f 0b ud2 4da: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) ptep_modify_prot_commit(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:503 4e0: 0f 0b ud2 4e2: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) pte_to_swp_entry(): /home/sasha/linux-next/./arch/x86/include/asm/pgtable.h:885 4e8: 0f 0b ud2 ptep_set_numa(): /home/sasha/linux-next/include/asm-generic/pgtable.h:724 4ea: 0f 0b ud2 /home/sasha/linux-next/include/asm-generic/pgtable.h:727 4ec: 0f 0b ud2 arch_leave_lazy_mmu_mode(): /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:699 4ee: 0f 0b ud2 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-09-10 20:36 ` Sasha Levin @ 2014-09-10 23:00 ` Hugh Dickins -1 siblings, 0 replies; 86+ messages in thread From: Hugh Dickins @ 2014-09-10 23:00 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, Mel Gorman, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Wed, 10 Sep 2014, Sasha Levin wrote: > On 09/10/2014 03:09 PM, Hugh Dickins wrote: > > Thanks for supplying, but the change in inlining means that > > change_protection_range() and change_protection() are no longer > > relevant for these traces, we now need to see change_pte_range() > > instead, to confirm that what I expect are ptes are indeed ptes. > > > > If you can include line numbers (objdump -ld) in the disassembly, so > > much the better, but should be decipherable without. (Or objdump -Sd > > for source, but I often find that harder to unscramble, can't say why.) > > Here it is. Note that the source includes both of Mel's debug patches. > For reference, here's one trace of the issue with those patches: > > [ 3114.540976] kernel BUG at include/asm-generic/pgtable.h:724! > [ 3114.541857] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 3114.543112] Dumping ftrace buffer: > [ 3114.544056] (ftrace buffer empty) > [ 3114.545000] Modules linked in: > [ 3114.545717] CPU: 18 PID: 30217 Comm: trinity-c617 Tainted: G W 3.17.0-rc4-next-20140910-sasha-00032-g6825fb5-dirty #1137 > [ 3114.548058] task: ffff880415050000 ti: ffff88076f584000 task.ti: ffff88076f584000 > [ 3114.549284] RIP: 0010:[<ffffffff952e527a>] [<ffffffff952e527a>] change_pte_range+0x4ea/0x4f0 > [ 3114.550028] RSP: 0000:ffff88076f587d68 EFLAGS: 00010246 > [ 3114.550028] RAX: 0000000314625900 RBX: 0000000041218000 RCX: 0000000000000100 > [ 3114.550028] RDX: 0000000314625900 RSI: 0000000041218000 RDI: 0000000314625900 > [ 3114.550028] RBP: ffff88076f587dc8 R08: ffff8802cf973600 R09: 0000000000b50000 > [ 3114.550028] R10: 0000000000032c01 R11: 0000000000000008 R12: ffff8802a81070c0 > [ 3114.550028] R13: 8000000000000025 R14: 0000000041343000 R15: ffffc00000000fff > [ 3114.550028] FS: 00007fabb91c8700(0000) GS:ffff88025ec00000(0000) knlGS:0000000000000000 > [ 3114.550028] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 3114.550028] CR2: 00007fffdb7678e8 CR3: 0000000713935000 CR4: 00000000000006a0 > [ 3114.550028] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 3114.550028] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000050602 > [ 3114.550028] Stack: > [ 3114.550028] 0000000000000001 0000000314625900 0000000000000018 ffff8802685f2260 > [ 3114.550028] 0000000016840000 ffff8802cf973600 ffff880616840000 0000000041343000 > [ 3114.550028] ffff880108805048 0000000041005000 0000000041200000 0000000041343000 > [ 3114.550028] Call Trace: > [ 3114.550028] [<ffffffff952e5534>] change_protection+0x2b4/0x4e0 > [ 3114.550028] [<ffffffff952ff24b>] change_prot_numa+0x1b/0x40 > [ 3114.550028] [<ffffffff951adf16>] task_numa_work+0x1f6/0x330 > [ 3114.550028] [<ffffffff95193de4>] task_work_run+0xc4/0xf0 > [ 3114.550028] [<ffffffff95071477>] do_notify_resume+0x97/0xb0 > [ 3114.550028] [<ffffffff9850f06a>] int_signal+0x12/0x17 > [ 3114.550028] Code: 66 90 48 8b 7d b8 e8 e6 88 22 03 48 8b 45 b0 e9 6f ff ff ff 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b <0f> 0b 0f 0b 0f 0b 66 66 66 66 90 55 48 89 e5 41 57 49 89 d7 41 > [ 3114.550028] RIP [<ffffffff952e527a>] change_pte_range+0x4ea/0x4f0 > [ 3114.550028] RSP <ffff88076f587d68> > > And the disassembly: ... > /home/sasha/linux-next/mm/mprotect.c:105 > 31d: 48 8b 4d a8 mov -0x58(%rbp),%rcx > 321: 81 e1 01 03 00 00 and $0x301,%ecx > 327: 48 81 f9 00 02 00 00 cmp $0x200,%rcx > 32e: 0f 84 0b ff ff ff je 23f <change_pte_range+0x23f> > pte_val(): > /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:450 > 334: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 33c <change_pte_range+0x33c> > 33b: 00 > 337: R_X86_64_PC32 pv_mmu_ops+0xe3 > ptep_set_numa(): > /home/sasha/linux-next/include/asm-generic/pgtable.h:740 > 33c: 49 8b 3c 24 mov (%r12),%rdi > pte_val(): > /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:450 > 340: 0f 84 12 01 00 00 je 458 <change_pte_range+0x458> > 346: ff 14 25 00 00 00 00 callq *0x0 > 349: R_X86_64_32S pv_mmu_ops+0xe8 > pte_mknuma(): > /home/sasha/linux-next/include/asm-generic/pgtable.h:724 > 34d: a8 01 test $0x1,%al > 34f: 0f 84 95 01 00 00 je 4ea <change_pte_range+0x4ea> ... > ptep_set_numa(): > /home/sasha/linux-next/include/asm-generic/pgtable.h:724 > 4ea: 0f 0b ud2 Thanks, yes, there is enough in there to be sure that the ...900 is indeed the oldpte. I wasn't expecting that pv_mmu_ops function call, but there's no evidence that it does anything worse than just return in %rax what it's given in %rdi; and the second long on the stack is the -0x58(%rbp) from which oldpte is retrieved for !pte_numa(oldpte) at the beginning of the extract above. Hugh ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-09-10 23:00 ` Hugh Dickins 0 siblings, 0 replies; 86+ messages in thread From: Hugh Dickins @ 2014-09-10 23:00 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, Mel Gorman, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Wed, 10 Sep 2014, Sasha Levin wrote: > On 09/10/2014 03:09 PM, Hugh Dickins wrote: > > Thanks for supplying, but the change in inlining means that > > change_protection_range() and change_protection() are no longer > > relevant for these traces, we now need to see change_pte_range() > > instead, to confirm that what I expect are ptes are indeed ptes. > > > > If you can include line numbers (objdump -ld) in the disassembly, so > > much the better, but should be decipherable without. (Or objdump -Sd > > for source, but I often find that harder to unscramble, can't say why.) > > Here it is. Note that the source includes both of Mel's debug patches. > For reference, here's one trace of the issue with those patches: > > [ 3114.540976] kernel BUG at include/asm-generic/pgtable.h:724! > [ 3114.541857] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 3114.543112] Dumping ftrace buffer: > [ 3114.544056] (ftrace buffer empty) > [ 3114.545000] Modules linked in: > [ 3114.545717] CPU: 18 PID: 30217 Comm: trinity-c617 Tainted: G W 3.17.0-rc4-next-20140910-sasha-00032-g6825fb5-dirty #1137 > [ 3114.548058] task: ffff880415050000 ti: ffff88076f584000 task.ti: ffff88076f584000 > [ 3114.549284] RIP: 0010:[<ffffffff952e527a>] [<ffffffff952e527a>] change_pte_range+0x4ea/0x4f0 > [ 3114.550028] RSP: 0000:ffff88076f587d68 EFLAGS: 00010246 > [ 3114.550028] RAX: 0000000314625900 RBX: 0000000041218000 RCX: 0000000000000100 > [ 3114.550028] RDX: 0000000314625900 RSI: 0000000041218000 RDI: 0000000314625900 > [ 3114.550028] RBP: ffff88076f587dc8 R08: ffff8802cf973600 R09: 0000000000b50000 > [ 3114.550028] R10: 0000000000032c01 R11: 0000000000000008 R12: ffff8802a81070c0 > [ 3114.550028] R13: 8000000000000025 R14: 0000000041343000 R15: ffffc00000000fff > [ 3114.550028] FS: 00007fabb91c8700(0000) GS:ffff88025ec00000(0000) knlGS:0000000000000000 > [ 3114.550028] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 3114.550028] CR2: 00007fffdb7678e8 CR3: 0000000713935000 CR4: 00000000000006a0 > [ 3114.550028] DR0: 00000000006f0000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 3114.550028] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000050602 > [ 3114.550028] Stack: > [ 3114.550028] 0000000000000001 0000000314625900 0000000000000018 ffff8802685f2260 > [ 3114.550028] 0000000016840000 ffff8802cf973600 ffff880616840000 0000000041343000 > [ 3114.550028] ffff880108805048 0000000041005000 0000000041200000 0000000041343000 > [ 3114.550028] Call Trace: > [ 3114.550028] [<ffffffff952e5534>] change_protection+0x2b4/0x4e0 > [ 3114.550028] [<ffffffff952ff24b>] change_prot_numa+0x1b/0x40 > [ 3114.550028] [<ffffffff951adf16>] task_numa_work+0x1f6/0x330 > [ 3114.550028] [<ffffffff95193de4>] task_work_run+0xc4/0xf0 > [ 3114.550028] [<ffffffff95071477>] do_notify_resume+0x97/0xb0 > [ 3114.550028] [<ffffffff9850f06a>] int_signal+0x12/0x17 > [ 3114.550028] Code: 66 90 48 8b 7d b8 e8 e6 88 22 03 48 8b 45 b0 e9 6f ff ff ff 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b <0f> 0b 0f 0b 0f 0b 66 66 66 66 90 55 48 89 e5 41 57 49 89 d7 41 > [ 3114.550028] RIP [<ffffffff952e527a>] change_pte_range+0x4ea/0x4f0 > [ 3114.550028] RSP <ffff88076f587d68> > > And the disassembly: ... > /home/sasha/linux-next/mm/mprotect.c:105 > 31d: 48 8b 4d a8 mov -0x58(%rbp),%rcx > 321: 81 e1 01 03 00 00 and $0x301,%ecx > 327: 48 81 f9 00 02 00 00 cmp $0x200,%rcx > 32e: 0f 84 0b ff ff ff je 23f <change_pte_range+0x23f> > pte_val(): > /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:450 > 334: 48 83 3d 00 00 00 00 cmpq $0x0,0x0(%rip) # 33c <change_pte_range+0x33c> > 33b: 00 > 337: R_X86_64_PC32 pv_mmu_ops+0xe3 > ptep_set_numa(): > /home/sasha/linux-next/include/asm-generic/pgtable.h:740 > 33c: 49 8b 3c 24 mov (%r12),%rdi > pte_val(): > /home/sasha/linux-next/./arch/x86/include/asm/paravirt.h:450 > 340: 0f 84 12 01 00 00 je 458 <change_pte_range+0x458> > 346: ff 14 25 00 00 00 00 callq *0x0 > 349: R_X86_64_32S pv_mmu_ops+0xe8 > pte_mknuma(): > /home/sasha/linux-next/include/asm-generic/pgtable.h:724 > 34d: a8 01 test $0x1,%al > 34f: 0f 84 95 01 00 00 je 4ea <change_pte_range+0x4ea> ... > ptep_set_numa(): > /home/sasha/linux-next/include/asm-generic/pgtable.h:724 > 4ea: 0f 0b ud2 Thanks, yes, there is enough in there to be sure that the ...900 is indeed the oldpte. I wasn't expecting that pv_mmu_ops function call, but there's no evidence that it does anything worse than just return in %rax what it's given in %rdi; and the second long on the stack is the -0x58(%rbp) from which oldpte is retrieved for !pte_numa(oldpte) at the beginning of the extract above. Hugh -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-08-06 0:42 ` Hugh Dickins @ 2014-08-06 10:35 ` Mel Gorman -1 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-08-06 10:35 UTC (permalink / raw) To: Hugh Dickins Cc: Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Aneesh Kumar K.V, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Tue, Aug 05, 2014 at 05:42:03PM -0700, Hugh Dickins wrote: > > <SNIP> > > > > I'm attaching a preliminary pair of patches. The first which deals with > > ARCH_USES_NUMA_PROT_NONE and the second which is yours with a revised > > changelog. I'm adding Aneesh to the cc to look at the powerpc portion of > > the first patch. > > Thanks a lot, Mel. > > I am surprised by the ordering, but perhaps you meant nothing by it. I didn't mean anything by it. It was based on the order I looked at the patches in. Revisited c46a7c817, looked at ARCH_USES_NUMA_PROT_NONE issue to see if it had any potential impact to your patch and then moved on to your patch. > Isn't the first one a welcome but optional cleanup, and the second one > a fix that we need in 3.16-stable? Or does the fix actually depend in > some unstated way upon the cleanup, in powerpc-land perhaps? > It shouldn't as powerpc can use its old helpers. I've included Aneesh in the cc just in case. > Aside from that, for the first patch: yes, I heartily approve of the > disappearance of CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE and > CONFIG_ARCH_USES_NUMA_PROT_NONE. If you wish, add > Acked-by: Hugh Dickins <hughd@google.com> > but of course it's really Aneesh and powerpc who are the test of it. > Thanks. I have a second version finished for that which I'll send once this bug is addressed. > One thing I did wonder, though: at first I was reassured by the > VM_BUG_ON(!pte_present(pte)) you add to pte_mknuma(); but then thought > it would be better as VM_BUG_ON(!(val & _PAGE_PRESENT)), being stronger > - asserting that indeed we do not put NUMA hints on PROT_NONE areas. > (But I have not tested, perhaps such a VM_BUG_ON would actually fire.) > It shouldn't so I'll use the stronger test. Sasha, if it's not too late would you mind testing this patch in isolation as a -stable candidate for 3.16 please? It worked for me including within trinity but then again I was not seeing crashes with 3.16 either so I do not consider my trinity testing to be a reliable indicator. ---8<--- x86,mm: fix pte_special versus pte_numa Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 at mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels: where zap_pte_range() checks page->mapping to see if PageAnon(page). Those addresses fit struct pages for pfns d2001 and d2000, and in each dump a register or a stack slot showed d2001730 or d2000730: pte flags 0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has a hole between cfffffff and 100000000, which would need special access. Commit c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL pte no longer passes the pte_special() test, so zap_pte_range() goes on to try to access a non-existent struct page. Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). A hint that this was a problem was that c46a7c817e66 added pte_numa() test to vm_normal_page(), and moved its is_zero_pfn() test from slow to fast path: This was papering over a pte_special() snag when the zero page was encountered during zap. This patch reverts vm_normal_page() to how it was before, relying on pte_special(). It still appears that this patch may be incomplete: aren't there other places which need to be handling PROTNONE along with PRESENT? For example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, but on a PROT_NONE area, that would make it pte_special(). This is side-stepped by the fact that NUMA hinting faults skipped PROT_NONE VMAs and there are no grounds where a NUMA hinting fault on a PROT_NONE VMA would be interesting. Fixes: c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") Reported-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Hugh Dickins <hughd@google.com> Signed-off-by: Mel Gorman <mgorman@suse.de> Cc: stable@vger.kernel.org [3.16] --- arch/x86/include/asm/pgtable.h | 9 +++++++-- mm/memory.c | 7 +++---- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h index 0ec0560..aa97a07 100644 --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -131,8 +131,13 @@ static inline int pte_exec(pte_t pte) static inline int pte_special(pte_t pte) { - return (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_SPECIAL)) == - (_PAGE_PRESENT|_PAGE_SPECIAL); + /* + * See CONFIG_NUMA_BALANCING pte_numa in include/asm-generic/pgtable.h. + * On x86 we have _PAGE_BIT_NUMA == _PAGE_BIT_GLOBAL+1 == + * __PAGE_BIT_SOFTW1 == _PAGE_BIT_SPECIAL. + */ + return (pte_flags(pte) & _PAGE_SPECIAL) && + (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_PROTNONE)); } static inline unsigned long pte_pfn(pte_t pte) diff --git a/mm/memory.c b/mm/memory.c index 8b44f76..0a21f3d 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -751,7 +751,7 @@ struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn = pte_pfn(pte); if (HAVE_PTE_SPECIAL) { - if (likely(!pte_special(pte) || pte_numa(pte))) + if (likely(!pte_special(pte))) goto check_pfn; if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)) return NULL; @@ -777,15 +777,14 @@ struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr, } } + if (is_zero_pfn(pfn)) + return NULL; check_pfn: if (unlikely(pfn > highest_memmap_pfn)) { print_bad_pte(vma, addr, pte, NULL); return NULL; } - if (is_zero_pfn(pfn)) - return NULL; - /* * NOTE! We still have PageReserved() pages in the page tables. * eg. VDSO mappings can cause them to exist. ^ permalink raw reply related [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-06 10:35 ` Mel Gorman 0 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-08-06 10:35 UTC (permalink / raw) To: Hugh Dickins Cc: Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Aneesh Kumar K.V, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov On Tue, Aug 05, 2014 at 05:42:03PM -0700, Hugh Dickins wrote: > > <SNIP> > > > > I'm attaching a preliminary pair of patches. The first which deals with > > ARCH_USES_NUMA_PROT_NONE and the second which is yours with a revised > > changelog. I'm adding Aneesh to the cc to look at the powerpc portion of > > the first patch. > > Thanks a lot, Mel. > > I am surprised by the ordering, but perhaps you meant nothing by it. I didn't mean anything by it. It was based on the order I looked at the patches in. Revisited c46a7c817, looked at ARCH_USES_NUMA_PROT_NONE issue to see if it had any potential impact to your patch and then moved on to your patch. > Isn't the first one a welcome but optional cleanup, and the second one > a fix that we need in 3.16-stable? Or does the fix actually depend in > some unstated way upon the cleanup, in powerpc-land perhaps? > It shouldn't as powerpc can use its old helpers. I've included Aneesh in the cc just in case. > Aside from that, for the first patch: yes, I heartily approve of the > disappearance of CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE and > CONFIG_ARCH_USES_NUMA_PROT_NONE. If you wish, add > Acked-by: Hugh Dickins <hughd@google.com> > but of course it's really Aneesh and powerpc who are the test of it. > Thanks. I have a second version finished for that which I'll send once this bug is addressed. > One thing I did wonder, though: at first I was reassured by the > VM_BUG_ON(!pte_present(pte)) you add to pte_mknuma(); but then thought > it would be better as VM_BUG_ON(!(val & _PAGE_PRESENT)), being stronger > - asserting that indeed we do not put NUMA hints on PROT_NONE areas. > (But I have not tested, perhaps such a VM_BUG_ON would actually fire.) > It shouldn't so I'll use the stronger test. Sasha, if it's not too late would you mind testing this patch in isolation as a -stable candidate for 3.16 please? It worked for me including within trinity but then again I was not seeing crashes with 3.16 either so I do not consider my trinity testing to be a reliable indicator. ---8<--- x86,mm: fix pte_special versus pte_numa Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 at mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels: where zap_pte_range() checks page->mapping to see if PageAnon(page). Those addresses fit struct pages for pfns d2001 and d2000, and in each dump a register or a stack slot showed d2001730 or d2000730: pte flags 0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has a hole between cfffffff and 100000000, which would need special access. Commit c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL pte no longer passes the pte_special() test, so zap_pte_range() goes on to try to access a non-existent struct page. Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) to complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE). A hint that this was a problem was that c46a7c817e66 added pte_numa() test to vm_normal_page(), and moved its is_zero_pfn() test from slow to fast path: This was papering over a pte_special() snag when the zero page was encountered during zap. This patch reverts vm_normal_page() to how it was before, relying on pte_special(). It still appears that this patch may be incomplete: aren't there other places which need to be handling PROTNONE along with PRESENT? For example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, but on a PROT_NONE area, that would make it pte_special(). This is side-stepped by the fact that NUMA hinting faults skipped PROT_NONE VMAs and there are no grounds where a NUMA hinting fault on a PROT_NONE VMA would be interesting. Fixes: c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") Reported-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Hugh Dickins <hughd@google.com> Signed-off-by: Mel Gorman <mgorman@suse.de> Cc: stable@vger.kernel.org [3.16] --- arch/x86/include/asm/pgtable.h | 9 +++++++-- mm/memory.c | 7 +++---- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h index 0ec0560..aa97a07 100644 --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -131,8 +131,13 @@ static inline int pte_exec(pte_t pte) static inline int pte_special(pte_t pte) { - return (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_SPECIAL)) == - (_PAGE_PRESENT|_PAGE_SPECIAL); + /* + * See CONFIG_NUMA_BALANCING pte_numa in include/asm-generic/pgtable.h. + * On x86 we have _PAGE_BIT_NUMA == _PAGE_BIT_GLOBAL+1 == + * __PAGE_BIT_SOFTW1 == _PAGE_BIT_SPECIAL. + */ + return (pte_flags(pte) & _PAGE_SPECIAL) && + (pte_flags(pte) & (_PAGE_PRESENT|_PAGE_PROTNONE)); } static inline unsigned long pte_pfn(pte_t pte) diff --git a/mm/memory.c b/mm/memory.c index 8b44f76..0a21f3d 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -751,7 +751,7 @@ struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn = pte_pfn(pte); if (HAVE_PTE_SPECIAL) { - if (likely(!pte_special(pte) || pte_numa(pte))) + if (likely(!pte_special(pte))) goto check_pfn; if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)) return NULL; @@ -777,15 +777,14 @@ struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr, } } + if (is_zero_pfn(pfn)) + return NULL; check_pfn: if (unlikely(pfn > highest_memmap_pfn)) { print_bad_pte(vma, addr, pte, NULL); return NULL; } - if (is_zero_pfn(pfn)) - return NULL; - /* * NOTE! We still have PageReserved() pages in the page tables. * eg. VDSO mappings can cause them to exist. -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-08-05 14:44 ` Mel Gorman (?) @ 2014-08-06 7:14 ` Aneesh Kumar K.V -1 siblings, 0 replies; 86+ messages in thread From: Aneesh Kumar K.V @ 2014-08-06 7:14 UTC (permalink / raw) To: Mel Gorman, Hugh Dickins Cc: Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov, linuxppc-dev Mel Gorman <mgorman@suse.de> writes: > From d0c77a2b497da46c52792ead066d461e5111a594 Mon Sep 17 00:00:00 2001 > From: Mel Gorman <mgorman@suse.de> > Date: Tue, 5 Aug 2014 12:06:50 +0100 > Subject: [PATCH] mm: Remove misleading ARCH_USES_NUMA_PROT_NONE > > ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented > _PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and > relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting > fault scanner. This was found to be conceptually confusing with a lot of > implicit assumptions and it was asked that an alternative be found. > > Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the > PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap > PTE bits and shrunk the maximum possible swap size but it did not go far > enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA > but the relics still exist. > > This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary > duplication in powerpc vs the generic implementation by defining the types > the core NUMA helpers expected to exist from x86 with their ppc64 equivalent. > The unification for ppc64 is less than ideal because types do not exist > that the "generic" code expects to. This patch works around the problem > but it would be preferred if the powerpc people would look at this to see > if they have opinions on what might suit them better. > > Signed-off-by: Mel Gorman <mgorman@suse.de> > --- > arch/powerpc/include/asm/pgtable.h | 55 ++++++++------------------------------ > arch/x86/Kconfig | 1 - > include/asm-generic/pgtable.h | 35 ++++++++++++------------ > init/Kconfig | 11 -------- > 4 files changed, 29 insertions(+), 73 deletions(-) > .... > - > #define pmdp_set_numa pmdp_set_numa > static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > pmd_t *pmdp) > @@ -109,16 +71,21 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > return; > } > > -#define pmd_mknonnuma pmd_mknonnuma > -static inline pmd_t pmd_mknonnuma(pmd_t pmd) > +/* > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist > + * which was inherited from x86. For the purposes of powerpc pte_basic_t is > + * equivalent > + */ > +#define pteval_t pte_basic_t > +#define pmdval_t pmd_t > +static inline pteval_t pte_flags(pte_t pte) > { > - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); > + return pte_val(pte) & PAGE_PROT_BITS; PAGE_PROT_BITS don't get the _PAGE_NUMA and _PAGE_PRESENT. I will have to check further to find out why the mask doesn't include _PAGE_PRESENT. > } > > -#define pmd_mknuma pmd_mknuma > -static inline pmd_t pmd_mknuma(pmd_t pmd) > +static inline pteval_t pmd_flags(pte_t pte) > { static inline pmdval_t ? > - return pte_pmd(pte_mknuma(pmd_pte(pmd))); > + return pmd_val(pte) & PAGE_PROT_BITS; > } > -aneesh ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-06 7:14 ` Aneesh Kumar K.V 0 siblings, 0 replies; 86+ messages in thread From: Aneesh Kumar K.V @ 2014-08-06 7:14 UTC (permalink / raw) To: Mel Gorman, Hugh Dickins Cc: Rik van Riel, linuxppc-dev, Peter Zijlstra, Johannes Weiner, LKML, Cyrill Gorcunov, linux-mm, Sasha Levin, Dave Jones, Andrew Morton, Kirill A. Shutemov Mel Gorman <mgorman@suse.de> writes: > From d0c77a2b497da46c52792ead066d461e5111a594 Mon Sep 17 00:00:00 2001 > From: Mel Gorman <mgorman@suse.de> > Date: Tue, 5 Aug 2014 12:06:50 +0100 > Subject: [PATCH] mm: Remove misleading ARCH_USES_NUMA_PROT_NONE > > ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented > _PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and > relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting > fault scanner. This was found to be conceptually confusing with a lot of > implicit assumptions and it was asked that an alternative be found. > > Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the > PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap > PTE bits and shrunk the maximum possible swap size but it did not go far > enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA > but the relics still exist. > > This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary > duplication in powerpc vs the generic implementation by defining the types > the core NUMA helpers expected to exist from x86 with their ppc64 equivalent. > The unification for ppc64 is less than ideal because types do not exist > that the "generic" code expects to. This patch works around the problem > but it would be preferred if the powerpc people would look at this to see > if they have opinions on what might suit them better. > > Signed-off-by: Mel Gorman <mgorman@suse.de> > --- > arch/powerpc/include/asm/pgtable.h | 55 ++++++++------------------------------ > arch/x86/Kconfig | 1 - > include/asm-generic/pgtable.h | 35 ++++++++++++------------ > init/Kconfig | 11 -------- > 4 files changed, 29 insertions(+), 73 deletions(-) > .... > - > #define pmdp_set_numa pmdp_set_numa > static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > pmd_t *pmdp) > @@ -109,16 +71,21 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > return; > } > > -#define pmd_mknonnuma pmd_mknonnuma > -static inline pmd_t pmd_mknonnuma(pmd_t pmd) > +/* > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist > + * which was inherited from x86. For the purposes of powerpc pte_basic_t is > + * equivalent > + */ > +#define pteval_t pte_basic_t > +#define pmdval_t pmd_t > +static inline pteval_t pte_flags(pte_t pte) > { > - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); > + return pte_val(pte) & PAGE_PROT_BITS; PAGE_PROT_BITS don't get the _PAGE_NUMA and _PAGE_PRESENT. I will have to check further to find out why the mask doesn't include _PAGE_PRESENT. > } > > -#define pmd_mknuma pmd_mknuma > -static inline pmd_t pmd_mknuma(pmd_t pmd) > +static inline pteval_t pmd_flags(pte_t pte) > { static inline pmdval_t ? > - return pte_pmd(pte_mknuma(pmd_pte(pmd))); > + return pmd_val(pte) & PAGE_PROT_BITS; > } > -aneesh ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-06 7:14 ` Aneesh Kumar K.V 0 siblings, 0 replies; 86+ messages in thread From: Aneesh Kumar K.V @ 2014-08-06 7:14 UTC (permalink / raw) To: Mel Gorman, Hugh Dickins Cc: Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov, linuxppc-dev Mel Gorman <mgorman@suse.de> writes: > From d0c77a2b497da46c52792ead066d461e5111a594 Mon Sep 17 00:00:00 2001 > From: Mel Gorman <mgorman@suse.de> > Date: Tue, 5 Aug 2014 12:06:50 +0100 > Subject: [PATCH] mm: Remove misleading ARCH_USES_NUMA_PROT_NONE > > ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented > _PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and > relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting > fault scanner. This was found to be conceptually confusing with a lot of > implicit assumptions and it was asked that an alternative be found. > > Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the > PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap > PTE bits and shrunk the maximum possible swap size but it did not go far > enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA > but the relics still exist. > > This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary > duplication in powerpc vs the generic implementation by defining the types > the core NUMA helpers expected to exist from x86 with their ppc64 equivalent. > The unification for ppc64 is less than ideal because types do not exist > that the "generic" code expects to. This patch works around the problem > but it would be preferred if the powerpc people would look at this to see > if they have opinions on what might suit them better. > > Signed-off-by: Mel Gorman <mgorman@suse.de> > --- > arch/powerpc/include/asm/pgtable.h | 55 ++++++++------------------------------ > arch/x86/Kconfig | 1 - > include/asm-generic/pgtable.h | 35 ++++++++++++------------ > init/Kconfig | 11 -------- > 4 files changed, 29 insertions(+), 73 deletions(-) > .... > - > #define pmdp_set_numa pmdp_set_numa > static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > pmd_t *pmdp) > @@ -109,16 +71,21 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > return; > } > > -#define pmd_mknonnuma pmd_mknonnuma > -static inline pmd_t pmd_mknonnuma(pmd_t pmd) > +/* > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist > + * which was inherited from x86. For the purposes of powerpc pte_basic_t is > + * equivalent > + */ > +#define pteval_t pte_basic_t > +#define pmdval_t pmd_t > +static inline pteval_t pte_flags(pte_t pte) > { > - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); > + return pte_val(pte) & PAGE_PROT_BITS; PAGE_PROT_BITS don't get the _PAGE_NUMA and _PAGE_PRESENT. I will have to check further to find out why the mask doesn't include _PAGE_PRESENT. > } > > -#define pmd_mknuma pmd_mknuma > -static inline pmd_t pmd_mknuma(pmd_t pmd) > +static inline pteval_t pmd_flags(pte_t pte) > { static inline pmdval_t ? > - return pte_pmd(pte_mknuma(pmd_pte(pmd))); > + return pmd_val(pte) & PAGE_PROT_BITS; > } > -aneesh -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-08-06 7:14 ` Aneesh Kumar K.V (?) @ 2014-08-06 10:23 ` Mel Gorman -1 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-08-06 10:23 UTC (permalink / raw) To: Aneesh Kumar K.V Cc: Hugh Dickins, Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov, linuxppc-dev On Wed, Aug 06, 2014 at 12:44:45PM +0530, Aneesh Kumar K.V wrote: > > -#define pmd_mknonnuma pmd_mknonnuma > > -static inline pmd_t pmd_mknonnuma(pmd_t pmd) > > +/* > > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist > > + * which was inherited from x86. For the purposes of powerpc pte_basic_t is > > + * equivalent > > + */ > > +#define pteval_t pte_basic_t > > +#define pmdval_t pmd_t > > +static inline pteval_t pte_flags(pte_t pte) > > { > > - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); > > + return pte_val(pte) & PAGE_PROT_BITS; > > PAGE_PROT_BITS don't get the _PAGE_NUMA and _PAGE_PRESENT. I will have > to check further to find out why the mask doesn't include > _PAGE_PRESENT. > Dumb of me, not sure how I managed that. For the purposes of what is required it doesn't matter what PAGE_PROT_BITS does. It is clearer if there is a mask that defines what bits are of interest to the generic helpers which is what this version attempts to do. It's not tested on powerpc at all unfortunately. ---8<--- mm: Remove misleading ARCH_USES_NUMA_PROT_NONE ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented _PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting fault scanner. This was found to be conceptually confusing with a lot of implicit assumptions and it was asked that an alternative be found. Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap PTE bits and shrunk the maximum possible swap size but it did not go far enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA but the relics still exist. This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary duplication in powerpc vs the generic implementation by defining the types the core NUMA helpers expected to exist from x86 with their ppc64 equivalent. This necessitated that a PTE bit mask be created that identified the bits that distinguish present from NUMA pte entries but it is expected this will only differ between arches based on _PAGE_PROTNONE. The naming for the generic helpers was taken from x86 originally but ppc64 has types that are equivalent for the purposes of the helper so they are mapped instead of duplicating code. Signed-off-by: Mel Gorman <mgorman@suse.de> --- arch/powerpc/include/asm/pgtable.h | 57 ++++++++--------------------------- arch/powerpc/include/asm/pte-common.h | 5 +++ arch/x86/Kconfig | 1 - arch/x86/include/asm/pgtable_types.h | 7 +++++ include/asm-generic/pgtable.h | 27 ++++++----------- init/Kconfig | 11 ------- 6 files changed, 33 insertions(+), 75 deletions(-) diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h index d98c1ec..beeb09e 100644 --- a/arch/powerpc/include/asm/pgtable.h +++ b/arch/powerpc/include/asm/pgtable.h @@ -38,10 +38,9 @@ static inline int pte_none(pte_t pte) { return (pte_val(pte) & ~_PTE_NONE_MASK) static inline pgprot_t pte_pgprot(pte_t pte) { return __pgprot(pte_val(pte) & PAGE_PROT_BITS); } #ifdef CONFIG_NUMA_BALANCING - static inline int pte_present(pte_t pte) { - return pte_val(pte) & (_PAGE_PRESENT | _PAGE_NUMA); + return pte_val(pte) & _PAGE_NUMA_MASK; } #define pte_present_nonuma pte_present_nonuma @@ -50,37 +49,6 @@ static inline int pte_present_nonuma(pte_t pte) return pte_val(pte) & (_PAGE_PRESENT); } -#define pte_numa pte_numa -static inline int pte_numa(pte_t pte) -{ - return (pte_val(pte) & - (_PAGE_NUMA|_PAGE_PRESENT)) == _PAGE_NUMA; -} - -#define pte_mknonnuma pte_mknonnuma -static inline pte_t pte_mknonnuma(pte_t pte) -{ - pte_val(pte) &= ~_PAGE_NUMA; - pte_val(pte) |= _PAGE_PRESENT | _PAGE_ACCESSED; - return pte; -} - -#define pte_mknuma pte_mknuma -static inline pte_t pte_mknuma(pte_t pte) -{ - /* - * We should not set _PAGE_NUMA on non present ptes. Also clear the - * present bit so that hash_page will return 1 and we collect this - * as numa fault. - */ - if (pte_present(pte)) { - pte_val(pte) |= _PAGE_NUMA; - pte_val(pte) &= ~_PAGE_PRESENT; - } else - VM_BUG_ON(1); - return pte; -} - #define ptep_set_numa ptep_set_numa static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, pte_t *ptep) @@ -92,12 +60,6 @@ static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, return; } -#define pmd_numa pmd_numa -static inline int pmd_numa(pmd_t pmd) -{ - return pte_numa(pmd_pte(pmd)); -} - #define pmdp_set_numa pmdp_set_numa static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp) @@ -109,16 +71,21 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, return; } -#define pmd_mknonnuma pmd_mknonnuma -static inline pmd_t pmd_mknonnuma(pmd_t pmd) +/* + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist + * which was inherited from x86. For the purposes of powerpc pte_basic_t and + * pmd_t are equivalent + */ +#define pteval_t pte_basic_t +#define pmdval_t pmd_t +static inline pteval_t ptenuma_flags(pte_t pte) { - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); + return pte_val(pte) & _PAGE_NUMA_MASK; } -#define pmd_mknuma pmd_mknuma -static inline pmd_t pmd_mknuma(pmd_t pmd) +static inline pmdval_t pmdnuma_flags(pte_t pte) { - return pte_pmd(pte_mknuma(pmd_pte(pmd))); + return pmd_val(pte) & _PAGE_NUMA_MASK; } # else diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h index 8d1569c..e040c35 100644 --- a/arch/powerpc/include/asm/pte-common.h +++ b/arch/powerpc/include/asm/pte-common.h @@ -98,6 +98,11 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void); _PAGE_USER | _PAGE_ACCESSED | \ _PAGE_RW | _PAGE_HWWRITE | _PAGE_DIRTY | _PAGE_EXEC) +#ifdef CONFIG_NUMA_BALANCING +/* Mask of bits that distinguish present and numa ptes */ +#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PRESENT) +#endif + /* * We define 2 sets of base prot bits, one for basic pages (ie, * cacheable kernel and user pages) and one for non cacheable diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index d24887b..0a3f32b 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -28,7 +28,6 @@ config X86 select HAVE_UNSTABLE_SCHED_CLOCK select ARCH_SUPPORTS_NUMA_BALANCING if X86_64 select ARCH_SUPPORTS_INT128 if X86_64 - select ARCH_WANTS_PROT_NUMA_PROT_NONE select HAVE_IDE select HAVE_OPROFILE select HAVE_PCSPKR_PLATFORM diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h index f216963..34ffe7e 100644 --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -129,6 +129,13 @@ _PAGE_SOFT_DIRTY | _PAGE_NUMA) #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE | _PAGE_NUMA) +#ifdef CONFIG_NUMA_BALANCING +/* Set of bits that distinguishes present, prot_none and numa ptes */ +#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT) +#define ptenuma_flags pte_flags +#define pmdnuma_flags pmd_flags +#endif /* CONFIG_NUMA_BALANCING */ + #define _PAGE_CACHE_MASK (_PAGE_PCD | _PAGE_PWT) #define _PAGE_CACHE_WB (0) #define _PAGE_CACHE_WC (_PAGE_PWT) diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h index 53b2acc..196c124 100644 --- a/include/asm-generic/pgtable.h +++ b/include/asm-generic/pgtable.h @@ -660,11 +660,12 @@ static inline int pmd_trans_unstable(pmd_t *pmd) } #ifdef CONFIG_NUMA_BALANCING -#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE /* - * _PAGE_NUMA works identical to _PAGE_PROTNONE (it's actually the - * same bit too). It's set only when _PAGE_PRESET is not set and it's - * never set if _PAGE_PRESENT is set. + * _PAGE_NUMA distinguishes between an unmapped page table entry, an entry that + * is protected for PROT_NONE and a NUMA hinting fault entry. If the + * architecture defines __PAGE_PROTNONE then it should take that into account + * but those that do not can rely on the fact that the NUMA hinting scanner + * skips inaccessible VMAs. * * pte/pmd_present() returns true if pte/pmd_numa returns true. Page * fault triggers on those regions if pte/pmd_numa returns true @@ -673,16 +674,14 @@ static inline int pmd_trans_unstable(pmd_t *pmd) #ifndef pte_numa static inline int pte_numa(pte_t pte) { - return (pte_flags(pte) & - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; + return (ptenuma_flags(pte) & _PAGE_NUMA_MASK) == _PAGE_NUMA; } #endif #ifndef pmd_numa static inline int pmd_numa(pmd_t pmd) { - return (pmd_flags(pmd) & - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; + return (pmdnuma_flags(pmd) & _PAGE_NUMA_MASK) == _PAGE_NUMA; } #endif @@ -722,6 +721,8 @@ static inline pte_t pte_mknuma(pte_t pte) { pteval_t val = pte_val(pte); + VM_BUG_ON(!(val & _PAGE_PRESENT)); + val &= ~_PAGE_PRESENT; val |= _PAGE_NUMA; @@ -765,16 +766,6 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, } #endif #else -extern int pte_numa(pte_t pte); -extern int pmd_numa(pmd_t pmd); -extern pte_t pte_mknonnuma(pte_t pte); -extern pmd_t pmd_mknonnuma(pmd_t pmd); -extern pte_t pte_mknuma(pte_t pte); -extern pmd_t pmd_mknuma(pmd_t pmd); -extern void ptep_set_numa(struct mm_struct *mm, unsigned long addr, pte_t *ptep); -extern void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp); -#endif /* CONFIG_ARCH_USES_NUMA_PROT_NONE */ -#else static inline int pmd_numa(pmd_t pmd) { return 0; diff --git a/init/Kconfig b/init/Kconfig index 9d76b99..60fa415 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -844,17 +844,6 @@ config ARCH_SUPPORTS_INT128 config ARCH_WANT_NUMA_VARIABLE_LOCALITY bool -# -# For architectures that are willing to define _PAGE_NUMA as _PAGE_PROTNONE -config ARCH_WANTS_PROT_NUMA_PROT_NONE - bool - -config ARCH_USES_NUMA_PROT_NONE - bool - default y - depends on ARCH_WANTS_PROT_NUMA_PROT_NONE - depends on NUMA_BALANCING - config NUMA_BALANCING_DEFAULT_ENABLED bool "Automatically enable NUMA aware memory/task placement" default y ^ permalink raw reply related [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-06 10:23 ` Mel Gorman 0 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-08-06 10:23 UTC (permalink / raw) To: Aneesh Kumar K.V Cc: Rik van Riel, linuxppc-dev, Peter Zijlstra, Johannes Weiner, Hugh Dickins, LKML, Cyrill Gorcunov, linux-mm, Sasha Levin, Dave Jones, Andrew Morton, Kirill A. Shutemov On Wed, Aug 06, 2014 at 12:44:45PM +0530, Aneesh Kumar K.V wrote: > > -#define pmd_mknonnuma pmd_mknonnuma > > -static inline pmd_t pmd_mknonnuma(pmd_t pmd) > > +/* > > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist > > + * which was inherited from x86. For the purposes of powerpc pte_basic_t is > > + * equivalent > > + */ > > +#define pteval_t pte_basic_t > > +#define pmdval_t pmd_t > > +static inline pteval_t pte_flags(pte_t pte) > > { > > - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); > > + return pte_val(pte) & PAGE_PROT_BITS; > > PAGE_PROT_BITS don't get the _PAGE_NUMA and _PAGE_PRESENT. I will have > to check further to find out why the mask doesn't include > _PAGE_PRESENT. > Dumb of me, not sure how I managed that. For the purposes of what is required it doesn't matter what PAGE_PROT_BITS does. It is clearer if there is a mask that defines what bits are of interest to the generic helpers which is what this version attempts to do. It's not tested on powerpc at all unfortunately. ---8<--- mm: Remove misleading ARCH_USES_NUMA_PROT_NONE ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented _PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting fault scanner. This was found to be conceptually confusing with a lot of implicit assumptions and it was asked that an alternative be found. Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap PTE bits and shrunk the maximum possible swap size but it did not go far enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA but the relics still exist. This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary duplication in powerpc vs the generic implementation by defining the types the core NUMA helpers expected to exist from x86 with their ppc64 equivalent. This necessitated that a PTE bit mask be created that identified the bits that distinguish present from NUMA pte entries but it is expected this will only differ between arches based on _PAGE_PROTNONE. The naming for the generic helpers was taken from x86 originally but ppc64 has types that are equivalent for the purposes of the helper so they are mapped instead of duplicating code. Signed-off-by: Mel Gorman <mgorman@suse.de> --- arch/powerpc/include/asm/pgtable.h | 57 ++++++++--------------------------- arch/powerpc/include/asm/pte-common.h | 5 +++ arch/x86/Kconfig | 1 - arch/x86/include/asm/pgtable_types.h | 7 +++++ include/asm-generic/pgtable.h | 27 ++++++----------- init/Kconfig | 11 ------- 6 files changed, 33 insertions(+), 75 deletions(-) diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h index d98c1ec..beeb09e 100644 --- a/arch/powerpc/include/asm/pgtable.h +++ b/arch/powerpc/include/asm/pgtable.h @@ -38,10 +38,9 @@ static inline int pte_none(pte_t pte) { return (pte_val(pte) & ~_PTE_NONE_MASK) static inline pgprot_t pte_pgprot(pte_t pte) { return __pgprot(pte_val(pte) & PAGE_PROT_BITS); } #ifdef CONFIG_NUMA_BALANCING - static inline int pte_present(pte_t pte) { - return pte_val(pte) & (_PAGE_PRESENT | _PAGE_NUMA); + return pte_val(pte) & _PAGE_NUMA_MASK; } #define pte_present_nonuma pte_present_nonuma @@ -50,37 +49,6 @@ static inline int pte_present_nonuma(pte_t pte) return pte_val(pte) & (_PAGE_PRESENT); } -#define pte_numa pte_numa -static inline int pte_numa(pte_t pte) -{ - return (pte_val(pte) & - (_PAGE_NUMA|_PAGE_PRESENT)) == _PAGE_NUMA; -} - -#define pte_mknonnuma pte_mknonnuma -static inline pte_t pte_mknonnuma(pte_t pte) -{ - pte_val(pte) &= ~_PAGE_NUMA; - pte_val(pte) |= _PAGE_PRESENT | _PAGE_ACCESSED; - return pte; -} - -#define pte_mknuma pte_mknuma -static inline pte_t pte_mknuma(pte_t pte) -{ - /* - * We should not set _PAGE_NUMA on non present ptes. Also clear the - * present bit so that hash_page will return 1 and we collect this - * as numa fault. - */ - if (pte_present(pte)) { - pte_val(pte) |= _PAGE_NUMA; - pte_val(pte) &= ~_PAGE_PRESENT; - } else - VM_BUG_ON(1); - return pte; -} - #define ptep_set_numa ptep_set_numa static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, pte_t *ptep) @@ -92,12 +60,6 @@ static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, return; } -#define pmd_numa pmd_numa -static inline int pmd_numa(pmd_t pmd) -{ - return pte_numa(pmd_pte(pmd)); -} - #define pmdp_set_numa pmdp_set_numa static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp) @@ -109,16 +71,21 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, return; } -#define pmd_mknonnuma pmd_mknonnuma -static inline pmd_t pmd_mknonnuma(pmd_t pmd) +/* + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist + * which was inherited from x86. For the purposes of powerpc pte_basic_t and + * pmd_t are equivalent + */ +#define pteval_t pte_basic_t +#define pmdval_t pmd_t +static inline pteval_t ptenuma_flags(pte_t pte) { - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); + return pte_val(pte) & _PAGE_NUMA_MASK; } -#define pmd_mknuma pmd_mknuma -static inline pmd_t pmd_mknuma(pmd_t pmd) +static inline pmdval_t pmdnuma_flags(pte_t pte) { - return pte_pmd(pte_mknuma(pmd_pte(pmd))); + return pmd_val(pte) & _PAGE_NUMA_MASK; } # else diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h index 8d1569c..e040c35 100644 --- a/arch/powerpc/include/asm/pte-common.h +++ b/arch/powerpc/include/asm/pte-common.h @@ -98,6 +98,11 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void); _PAGE_USER | _PAGE_ACCESSED | \ _PAGE_RW | _PAGE_HWWRITE | _PAGE_DIRTY | _PAGE_EXEC) +#ifdef CONFIG_NUMA_BALANCING +/* Mask of bits that distinguish present and numa ptes */ +#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PRESENT) +#endif + /* * We define 2 sets of base prot bits, one for basic pages (ie, * cacheable kernel and user pages) and one for non cacheable diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index d24887b..0a3f32b 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -28,7 +28,6 @@ config X86 select HAVE_UNSTABLE_SCHED_CLOCK select ARCH_SUPPORTS_NUMA_BALANCING if X86_64 select ARCH_SUPPORTS_INT128 if X86_64 - select ARCH_WANTS_PROT_NUMA_PROT_NONE select HAVE_IDE select HAVE_OPROFILE select HAVE_PCSPKR_PLATFORM diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h index f216963..34ffe7e 100644 --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -129,6 +129,13 @@ _PAGE_SOFT_DIRTY | _PAGE_NUMA) #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE | _PAGE_NUMA) +#ifdef CONFIG_NUMA_BALANCING +/* Set of bits that distinguishes present, prot_none and numa ptes */ +#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT) +#define ptenuma_flags pte_flags +#define pmdnuma_flags pmd_flags +#endif /* CONFIG_NUMA_BALANCING */ + #define _PAGE_CACHE_MASK (_PAGE_PCD | _PAGE_PWT) #define _PAGE_CACHE_WB (0) #define _PAGE_CACHE_WC (_PAGE_PWT) diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h index 53b2acc..196c124 100644 --- a/include/asm-generic/pgtable.h +++ b/include/asm-generic/pgtable.h @@ -660,11 +660,12 @@ static inline int pmd_trans_unstable(pmd_t *pmd) } #ifdef CONFIG_NUMA_BALANCING -#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE /* - * _PAGE_NUMA works identical to _PAGE_PROTNONE (it's actually the - * same bit too). It's set only when _PAGE_PRESET is not set and it's - * never set if _PAGE_PRESENT is set. + * _PAGE_NUMA distinguishes between an unmapped page table entry, an entry that + * is protected for PROT_NONE and a NUMA hinting fault entry. If the + * architecture defines __PAGE_PROTNONE then it should take that into account + * but those that do not can rely on the fact that the NUMA hinting scanner + * skips inaccessible VMAs. * * pte/pmd_present() returns true if pte/pmd_numa returns true. Page * fault triggers on those regions if pte/pmd_numa returns true @@ -673,16 +674,14 @@ static inline int pmd_trans_unstable(pmd_t *pmd) #ifndef pte_numa static inline int pte_numa(pte_t pte) { - return (pte_flags(pte) & - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; + return (ptenuma_flags(pte) & _PAGE_NUMA_MASK) == _PAGE_NUMA; } #endif #ifndef pmd_numa static inline int pmd_numa(pmd_t pmd) { - return (pmd_flags(pmd) & - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; + return (pmdnuma_flags(pmd) & _PAGE_NUMA_MASK) == _PAGE_NUMA; } #endif @@ -722,6 +721,8 @@ static inline pte_t pte_mknuma(pte_t pte) { pteval_t val = pte_val(pte); + VM_BUG_ON(!(val & _PAGE_PRESENT)); + val &= ~_PAGE_PRESENT; val |= _PAGE_NUMA; @@ -765,16 +766,6 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, } #endif #else -extern int pte_numa(pte_t pte); -extern int pmd_numa(pmd_t pmd); -extern pte_t pte_mknonnuma(pte_t pte); -extern pmd_t pmd_mknonnuma(pmd_t pmd); -extern pte_t pte_mknuma(pte_t pte); -extern pmd_t pmd_mknuma(pmd_t pmd); -extern void ptep_set_numa(struct mm_struct *mm, unsigned long addr, pte_t *ptep); -extern void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp); -#endif /* CONFIG_ARCH_USES_NUMA_PROT_NONE */ -#else static inline int pmd_numa(pmd_t pmd) { return 0; diff --git a/init/Kconfig b/init/Kconfig index 9d76b99..60fa415 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -844,17 +844,6 @@ config ARCH_SUPPORTS_INT128 config ARCH_WANT_NUMA_VARIABLE_LOCALITY bool -# -# For architectures that are willing to define _PAGE_NUMA as _PAGE_PROTNONE -config ARCH_WANTS_PROT_NUMA_PROT_NONE - bool - -config ARCH_USES_NUMA_PROT_NONE - bool - default y - depends on ARCH_WANTS_PROT_NUMA_PROT_NONE - depends on NUMA_BALANCING - config NUMA_BALANCING_DEFAULT_ENABLED bool "Automatically enable NUMA aware memory/task placement" default y ^ permalink raw reply related [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-06 10:23 ` Mel Gorman 0 siblings, 0 replies; 86+ messages in thread From: Mel Gorman @ 2014-08-06 10:23 UTC (permalink / raw) To: Aneesh Kumar K.V Cc: Hugh Dickins, Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov, linuxppc-dev On Wed, Aug 06, 2014 at 12:44:45PM +0530, Aneesh Kumar K.V wrote: > > -#define pmd_mknonnuma pmd_mknonnuma > > -static inline pmd_t pmd_mknonnuma(pmd_t pmd) > > +/* > > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist > > + * which was inherited from x86. For the purposes of powerpc pte_basic_t is > > + * equivalent > > + */ > > +#define pteval_t pte_basic_t > > +#define pmdval_t pmd_t > > +static inline pteval_t pte_flags(pte_t pte) > > { > > - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); > > + return pte_val(pte) & PAGE_PROT_BITS; > > PAGE_PROT_BITS don't get the _PAGE_NUMA and _PAGE_PRESENT. I will have > to check further to find out why the mask doesn't include > _PAGE_PRESENT. > Dumb of me, not sure how I managed that. For the purposes of what is required it doesn't matter what PAGE_PROT_BITS does. It is clearer if there is a mask that defines what bits are of interest to the generic helpers which is what this version attempts to do. It's not tested on powerpc at all unfortunately. ---8<--- mm: Remove misleading ARCH_USES_NUMA_PROT_NONE ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented _PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting fault scanner. This was found to be conceptually confusing with a lot of implicit assumptions and it was asked that an alternative be found. Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap PTE bits and shrunk the maximum possible swap size but it did not go far enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA but the relics still exist. This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary duplication in powerpc vs the generic implementation by defining the types the core NUMA helpers expected to exist from x86 with their ppc64 equivalent. This necessitated that a PTE bit mask be created that identified the bits that distinguish present from NUMA pte entries but it is expected this will only differ between arches based on _PAGE_PROTNONE. The naming for the generic helpers was taken from x86 originally but ppc64 has types that are equivalent for the purposes of the helper so they are mapped instead of duplicating code. Signed-off-by: Mel Gorman <mgorman@suse.de> --- arch/powerpc/include/asm/pgtable.h | 57 ++++++++--------------------------- arch/powerpc/include/asm/pte-common.h | 5 +++ arch/x86/Kconfig | 1 - arch/x86/include/asm/pgtable_types.h | 7 +++++ include/asm-generic/pgtable.h | 27 ++++++----------- init/Kconfig | 11 ------- 6 files changed, 33 insertions(+), 75 deletions(-) diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h index d98c1ec..beeb09e 100644 --- a/arch/powerpc/include/asm/pgtable.h +++ b/arch/powerpc/include/asm/pgtable.h @@ -38,10 +38,9 @@ static inline int pte_none(pte_t pte) { return (pte_val(pte) & ~_PTE_NONE_MASK) static inline pgprot_t pte_pgprot(pte_t pte) { return __pgprot(pte_val(pte) & PAGE_PROT_BITS); } #ifdef CONFIG_NUMA_BALANCING - static inline int pte_present(pte_t pte) { - return pte_val(pte) & (_PAGE_PRESENT | _PAGE_NUMA); + return pte_val(pte) & _PAGE_NUMA_MASK; } #define pte_present_nonuma pte_present_nonuma @@ -50,37 +49,6 @@ static inline int pte_present_nonuma(pte_t pte) return pte_val(pte) & (_PAGE_PRESENT); } -#define pte_numa pte_numa -static inline int pte_numa(pte_t pte) -{ - return (pte_val(pte) & - (_PAGE_NUMA|_PAGE_PRESENT)) == _PAGE_NUMA; -} - -#define pte_mknonnuma pte_mknonnuma -static inline pte_t pte_mknonnuma(pte_t pte) -{ - pte_val(pte) &= ~_PAGE_NUMA; - pte_val(pte) |= _PAGE_PRESENT | _PAGE_ACCESSED; - return pte; -} - -#define pte_mknuma pte_mknuma -static inline pte_t pte_mknuma(pte_t pte) -{ - /* - * We should not set _PAGE_NUMA on non present ptes. Also clear the - * present bit so that hash_page will return 1 and we collect this - * as numa fault. - */ - if (pte_present(pte)) { - pte_val(pte) |= _PAGE_NUMA; - pte_val(pte) &= ~_PAGE_PRESENT; - } else - VM_BUG_ON(1); - return pte; -} - #define ptep_set_numa ptep_set_numa static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, pte_t *ptep) @@ -92,12 +60,6 @@ static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, return; } -#define pmd_numa pmd_numa -static inline int pmd_numa(pmd_t pmd) -{ - return pte_numa(pmd_pte(pmd)); -} - #define pmdp_set_numa pmdp_set_numa static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp) @@ -109,16 +71,21 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, return; } -#define pmd_mknonnuma pmd_mknonnuma -static inline pmd_t pmd_mknonnuma(pmd_t pmd) +/* + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist + * which was inherited from x86. For the purposes of powerpc pte_basic_t and + * pmd_t are equivalent + */ +#define pteval_t pte_basic_t +#define pmdval_t pmd_t +static inline pteval_t ptenuma_flags(pte_t pte) { - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); + return pte_val(pte) & _PAGE_NUMA_MASK; } -#define pmd_mknuma pmd_mknuma -static inline pmd_t pmd_mknuma(pmd_t pmd) +static inline pmdval_t pmdnuma_flags(pte_t pte) { - return pte_pmd(pte_mknuma(pmd_pte(pmd))); + return pmd_val(pte) & _PAGE_NUMA_MASK; } # else diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h index 8d1569c..e040c35 100644 --- a/arch/powerpc/include/asm/pte-common.h +++ b/arch/powerpc/include/asm/pte-common.h @@ -98,6 +98,11 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void); _PAGE_USER | _PAGE_ACCESSED | \ _PAGE_RW | _PAGE_HWWRITE | _PAGE_DIRTY | _PAGE_EXEC) +#ifdef CONFIG_NUMA_BALANCING +/* Mask of bits that distinguish present and numa ptes */ +#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PRESENT) +#endif + /* * We define 2 sets of base prot bits, one for basic pages (ie, * cacheable kernel and user pages) and one for non cacheable diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index d24887b..0a3f32b 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -28,7 +28,6 @@ config X86 select HAVE_UNSTABLE_SCHED_CLOCK select ARCH_SUPPORTS_NUMA_BALANCING if X86_64 select ARCH_SUPPORTS_INT128 if X86_64 - select ARCH_WANTS_PROT_NUMA_PROT_NONE select HAVE_IDE select HAVE_OPROFILE select HAVE_PCSPKR_PLATFORM diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h index f216963..34ffe7e 100644 --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -129,6 +129,13 @@ _PAGE_SOFT_DIRTY | _PAGE_NUMA) #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE | _PAGE_NUMA) +#ifdef CONFIG_NUMA_BALANCING +/* Set of bits that distinguishes present, prot_none and numa ptes */ +#define _PAGE_NUMA_MASK (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT) +#define ptenuma_flags pte_flags +#define pmdnuma_flags pmd_flags +#endif /* CONFIG_NUMA_BALANCING */ + #define _PAGE_CACHE_MASK (_PAGE_PCD | _PAGE_PWT) #define _PAGE_CACHE_WB (0) #define _PAGE_CACHE_WC (_PAGE_PWT) diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h index 53b2acc..196c124 100644 --- a/include/asm-generic/pgtable.h +++ b/include/asm-generic/pgtable.h @@ -660,11 +660,12 @@ static inline int pmd_trans_unstable(pmd_t *pmd) } #ifdef CONFIG_NUMA_BALANCING -#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE /* - * _PAGE_NUMA works identical to _PAGE_PROTNONE (it's actually the - * same bit too). It's set only when _PAGE_PRESET is not set and it's - * never set if _PAGE_PRESENT is set. + * _PAGE_NUMA distinguishes between an unmapped page table entry, an entry that + * is protected for PROT_NONE and a NUMA hinting fault entry. If the + * architecture defines __PAGE_PROTNONE then it should take that into account + * but those that do not can rely on the fact that the NUMA hinting scanner + * skips inaccessible VMAs. * * pte/pmd_present() returns true if pte/pmd_numa returns true. Page * fault triggers on those regions if pte/pmd_numa returns true @@ -673,16 +674,14 @@ static inline int pmd_trans_unstable(pmd_t *pmd) #ifndef pte_numa static inline int pte_numa(pte_t pte) { - return (pte_flags(pte) & - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; + return (ptenuma_flags(pte) & _PAGE_NUMA_MASK) == _PAGE_NUMA; } #endif #ifndef pmd_numa static inline int pmd_numa(pmd_t pmd) { - return (pmd_flags(pmd) & - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; + return (pmdnuma_flags(pmd) & _PAGE_NUMA_MASK) == _PAGE_NUMA; } #endif @@ -722,6 +721,8 @@ static inline pte_t pte_mknuma(pte_t pte) { pteval_t val = pte_val(pte); + VM_BUG_ON(!(val & _PAGE_PRESENT)); + val &= ~_PAGE_PRESENT; val |= _PAGE_NUMA; @@ -765,16 +766,6 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, } #endif #else -extern int pte_numa(pte_t pte); -extern int pmd_numa(pmd_t pmd); -extern pte_t pte_mknonnuma(pte_t pte); -extern pmd_t pmd_mknonnuma(pmd_t pmd); -extern pte_t pte_mknuma(pte_t pte); -extern pmd_t pmd_mknuma(pmd_t pmd); -extern void ptep_set_numa(struct mm_struct *mm, unsigned long addr, pte_t *ptep); -extern void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp); -#endif /* CONFIG_ARCH_USES_NUMA_PROT_NONE */ -#else static inline int pmd_numa(pmd_t pmd) { return 0; diff --git a/init/Kconfig b/init/Kconfig index 9d76b99..60fa415 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -844,17 +844,6 @@ config ARCH_SUPPORTS_INT128 config ARCH_WANT_NUMA_VARIABLE_LOCALITY bool -# -# For architectures that are willing to define _PAGE_NUMA as _PAGE_PROTNONE -config ARCH_WANTS_PROT_NUMA_PROT_NONE - bool - -config ARCH_USES_NUMA_PROT_NONE - bool - default y - depends on ARCH_WANTS_PROT_NUMA_PROT_NONE - depends on NUMA_BALANCING - config NUMA_BALANCING_DEFAULT_ENABLED bool "Automatically enable NUMA aware memory/task placement" default y -- 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] 86+ messages in thread
* Re: mm: BUG in unmap_page_range 2014-08-06 10:23 ` Mel Gorman (?) @ 2014-08-07 8:40 ` Aneesh Kumar K.V -1 siblings, 0 replies; 86+ messages in thread From: Aneesh Kumar K.V @ 2014-08-07 8:40 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov, linuxppc-dev Mel Gorman <mgorman@suse.de> writes: > On Wed, Aug 06, 2014 at 12:44:45PM +0530, Aneesh Kumar K.V wrote: >> > -#define pmd_mknonnuma pmd_mknonnuma >> > -static inline pmd_t pmd_mknonnuma(pmd_t pmd) >> > +/* >> > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist >> > + * which was inherited from x86. For the purposes of powerpc pte_basic_t is >> > + * equivalent >> > + */ >> > +#define pteval_t pte_basic_t >> > +#define pmdval_t pmd_t >> > +static inline pteval_t pte_flags(pte_t pte) >> > { >> > - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); >> > + return pte_val(pte) & PAGE_PROT_BITS; >> >> PAGE_PROT_BITS don't get the _PAGE_NUMA and _PAGE_PRESENT. I will have >> to check further to find out why the mask doesn't include >> _PAGE_PRESENT. >> > > Dumb of me, not sure how I managed that. For the purposes of what is required > it doesn't matter what PAGE_PROT_BITS does. It is clearer if there is a mask > that defines what bits are of interest to the generic helpers which is what > this version attempts to do. It's not tested on powerpc at all > unfortunately. Boot tested on ppc64. # grep numa /proc/vmstat numa_hit 156722 numa_miss 0 numa_foreign 0 numa_interleave 6365 numa_local 153457 numa_other 3265 numa_pte_updates 169 numa_huge_pte_updates 0 numa_hint_faults 150 numa_hint_faults_local 138 numa_pages_migrated 10 > > ---8<--- > mm: Remove misleading ARCH_USES_NUMA_PROT_NONE > > ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented > _PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and > relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting > fault scanner. This was found to be conceptually confusing with a lot of > implicit assumptions and it was asked that an alternative be found. > > Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the > PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap > PTE bits and shrunk the maximum possible swap size but it did not go far > enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA > but the relics still exist. > > This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary > duplication in powerpc vs the generic implementation by defining the types > the core NUMA helpers expected to exist from x86 with their ppc64 equivalent. > This necessitated that a PTE bit mask be created that identified the bits > that distinguish present from NUMA pte entries but it is expected this > will only differ between arches based on _PAGE_PROTNONE. The naming for > the generic helpers was taken from x86 originally but ppc64 has types that > are equivalent for the purposes of the helper so they are mapped instead > of duplicating code. > > Signed-off-by: Mel Gorman <mgorman@suse.de> > --- > arch/powerpc/include/asm/pgtable.h | 57 ++++++++--------------------------- > arch/powerpc/include/asm/pte-common.h | 5 +++ > arch/x86/Kconfig | 1 - > arch/x86/include/asm/pgtable_types.h | 7 +++++ > include/asm-generic/pgtable.h | 27 ++++++----------- > init/Kconfig | 11 ------- > 6 files changed, 33 insertions(+), 75 deletions(-) > > diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h > index d98c1ec..beeb09e 100644 > --- a/arch/powerpc/include/asm/pgtable.h > +++ b/arch/powerpc/include/asm/pgtable.h > @@ -38,10 +38,9 @@ static inline int pte_none(pte_t pte) { return (pte_val(pte) & ~_PTE_NONE_MASK) > static inline pgprot_t pte_pgprot(pte_t pte) { return __pgprot(pte_val(pte) & PAGE_PROT_BITS); } > > #ifdef CONFIG_NUMA_BALANCING > - > static inline int pte_present(pte_t pte) > { > - return pte_val(pte) & (_PAGE_PRESENT | _PAGE_NUMA); > + return pte_val(pte) & _PAGE_NUMA_MASK; > } > > #define pte_present_nonuma pte_present_nonuma > @@ -50,37 +49,6 @@ static inline int pte_present_nonuma(pte_t pte) > return pte_val(pte) & (_PAGE_PRESENT); > } > > -#define pte_numa pte_numa > -static inline int pte_numa(pte_t pte) > -{ > - return (pte_val(pte) & > - (_PAGE_NUMA|_PAGE_PRESENT)) == _PAGE_NUMA; > -} > - > -#define pte_mknonnuma pte_mknonnuma > -static inline pte_t pte_mknonnuma(pte_t pte) > -{ > - pte_val(pte) &= ~_PAGE_NUMA; > - pte_val(pte) |= _PAGE_PRESENT | _PAGE_ACCESSED; > - return pte; > -} > - > -#define pte_mknuma pte_mknuma > -static inline pte_t pte_mknuma(pte_t pte) > -{ > - /* > - * We should not set _PAGE_NUMA on non present ptes. Also clear the > - * present bit so that hash_page will return 1 and we collect this > - * as numa fault. > - */ > - if (pte_present(pte)) { > - pte_val(pte) |= _PAGE_NUMA; > - pte_val(pte) &= ~_PAGE_PRESENT; > - } else > - VM_BUG_ON(1); > - return pte; > -} > - > #define ptep_set_numa ptep_set_numa > static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, > pte_t *ptep) > @@ -92,12 +60,6 @@ static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, > return; > } > > -#define pmd_numa pmd_numa > -static inline int pmd_numa(pmd_t pmd) > -{ > - return pte_numa(pmd_pte(pmd)); > -} > - > #define pmdp_set_numa pmdp_set_numa > static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > pmd_t *pmdp) > @@ -109,16 +71,21 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > return; > } > > -#define pmd_mknonnuma pmd_mknonnuma > -static inline pmd_t pmd_mknonnuma(pmd_t pmd) > +/* > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist > + * which was inherited from x86. For the purposes of powerpc pte_basic_t and > + * pmd_t are equivalent > + */ > +#define pteval_t pte_basic_t > +#define pmdval_t pmd_t > +static inline pteval_t ptenuma_flags(pte_t pte) > { > - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); > + return pte_val(pte) & _PAGE_NUMA_MASK; > } > > -#define pmd_mknuma pmd_mknuma > -static inline pmd_t pmd_mknuma(pmd_t pmd) > +static inline pmdval_t pmdnuma_flags(pte_t pte) > { > - return pte_pmd(pte_mknuma(pmd_pte(pmd))); > + return pmd_val(pte) & _PAGE_NUMA_MASK; > } > > # else .... > --- a/include/asm-generic/pgtable.h > +++ b/include/asm-generic/pgtable.h > @@ -660,11 +660,12 @@ static inline int pmd_trans_unstable(pmd_t *pmd) > } > > #ifdef CONFIG_NUMA_BALANCING > -#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE > /* > - * _PAGE_NUMA works identical to _PAGE_PROTNONE (it's actually the > - * same bit too). It's set only when _PAGE_PRESET is not set and it's > - * never set if _PAGE_PRESENT is set. > + * _PAGE_NUMA distinguishes between an unmapped page table entry, an entry that > + * is protected for PROT_NONE and a NUMA hinting fault entry. If the > + * architecture defines __PAGE_PROTNONE then it should take that into account > + * but those that do not can rely on the fact that the NUMA hinting scanner > + * skips inaccessible VMAs. > * > * pte/pmd_present() returns true if pte/pmd_numa returns true. Page > * fault triggers on those regions if pte/pmd_numa returns true > @@ -673,16 +674,14 @@ static inline int pmd_trans_unstable(pmd_t *pmd) > #ifndef pte_numa > static inline int pte_numa(pte_t pte) > { > - return (pte_flags(pte) & > - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; > + return (ptenuma_flags(pte) & _PAGE_NUMA_MASK) == _PAGE_NUMA; > } Can we avoid & _PAGE_NUMA_MASK ?. I understand that you need that for x86 because you have #define ptenuma_flags pte_flags But on ppc64 you already have static inline pteval_t ptenuma_flags(pte_t pte) { return pte_val(pte) & _PAGE_NUMA_MASK; } -aneesh ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-07 8:40 ` Aneesh Kumar K.V 0 siblings, 0 replies; 86+ messages in thread From: Aneesh Kumar K.V @ 2014-08-07 8:40 UTC (permalink / raw) To: Mel Gorman Cc: Rik van Riel, linuxppc-dev, Peter Zijlstra, Johannes Weiner, Hugh Dickins, LKML, Cyrill Gorcunov, linux-mm, Sasha Levin, Dave Jones, Andrew Morton, Kirill A. Shutemov Mel Gorman <mgorman@suse.de> writes: > On Wed, Aug 06, 2014 at 12:44:45PM +0530, Aneesh Kumar K.V wrote: >> > -#define pmd_mknonnuma pmd_mknonnuma >> > -static inline pmd_t pmd_mknonnuma(pmd_t pmd) >> > +/* >> > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist >> > + * which was inherited from x86. For the purposes of powerpc pte_basic_t is >> > + * equivalent >> > + */ >> > +#define pteval_t pte_basic_t >> > +#define pmdval_t pmd_t >> > +static inline pteval_t pte_flags(pte_t pte) >> > { >> > - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); >> > + return pte_val(pte) & PAGE_PROT_BITS; >> >> PAGE_PROT_BITS don't get the _PAGE_NUMA and _PAGE_PRESENT. I will have >> to check further to find out why the mask doesn't include >> _PAGE_PRESENT. >> > > Dumb of me, not sure how I managed that. For the purposes of what is required > it doesn't matter what PAGE_PROT_BITS does. It is clearer if there is a mask > that defines what bits are of interest to the generic helpers which is what > this version attempts to do. It's not tested on powerpc at all > unfortunately. Boot tested on ppc64. # grep numa /proc/vmstat numa_hit 156722 numa_miss 0 numa_foreign 0 numa_interleave 6365 numa_local 153457 numa_other 3265 numa_pte_updates 169 numa_huge_pte_updates 0 numa_hint_faults 150 numa_hint_faults_local 138 numa_pages_migrated 10 > > ---8<--- > mm: Remove misleading ARCH_USES_NUMA_PROT_NONE > > ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented > _PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and > relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting > fault scanner. This was found to be conceptually confusing with a lot of > implicit assumptions and it was asked that an alternative be found. > > Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the > PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap > PTE bits and shrunk the maximum possible swap size but it did not go far > enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA > but the relics still exist. > > This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary > duplication in powerpc vs the generic implementation by defining the types > the core NUMA helpers expected to exist from x86 with their ppc64 equivalent. > This necessitated that a PTE bit mask be created that identified the bits > that distinguish present from NUMA pte entries but it is expected this > will only differ between arches based on _PAGE_PROTNONE. The naming for > the generic helpers was taken from x86 originally but ppc64 has types that > are equivalent for the purposes of the helper so they are mapped instead > of duplicating code. > > Signed-off-by: Mel Gorman <mgorman@suse.de> > --- > arch/powerpc/include/asm/pgtable.h | 57 ++++++++--------------------------- > arch/powerpc/include/asm/pte-common.h | 5 +++ > arch/x86/Kconfig | 1 - > arch/x86/include/asm/pgtable_types.h | 7 +++++ > include/asm-generic/pgtable.h | 27 ++++++----------- > init/Kconfig | 11 ------- > 6 files changed, 33 insertions(+), 75 deletions(-) > > diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h > index d98c1ec..beeb09e 100644 > --- a/arch/powerpc/include/asm/pgtable.h > +++ b/arch/powerpc/include/asm/pgtable.h > @@ -38,10 +38,9 @@ static inline int pte_none(pte_t pte) { return (pte_val(pte) & ~_PTE_NONE_MASK) > static inline pgprot_t pte_pgprot(pte_t pte) { return __pgprot(pte_val(pte) & PAGE_PROT_BITS); } > > #ifdef CONFIG_NUMA_BALANCING > - > static inline int pte_present(pte_t pte) > { > - return pte_val(pte) & (_PAGE_PRESENT | _PAGE_NUMA); > + return pte_val(pte) & _PAGE_NUMA_MASK; > } > > #define pte_present_nonuma pte_present_nonuma > @@ -50,37 +49,6 @@ static inline int pte_present_nonuma(pte_t pte) > return pte_val(pte) & (_PAGE_PRESENT); > } > > -#define pte_numa pte_numa > -static inline int pte_numa(pte_t pte) > -{ > - return (pte_val(pte) & > - (_PAGE_NUMA|_PAGE_PRESENT)) == _PAGE_NUMA; > -} > - > -#define pte_mknonnuma pte_mknonnuma > -static inline pte_t pte_mknonnuma(pte_t pte) > -{ > - pte_val(pte) &= ~_PAGE_NUMA; > - pte_val(pte) |= _PAGE_PRESENT | _PAGE_ACCESSED; > - return pte; > -} > - > -#define pte_mknuma pte_mknuma > -static inline pte_t pte_mknuma(pte_t pte) > -{ > - /* > - * We should not set _PAGE_NUMA on non present ptes. Also clear the > - * present bit so that hash_page will return 1 and we collect this > - * as numa fault. > - */ > - if (pte_present(pte)) { > - pte_val(pte) |= _PAGE_NUMA; > - pte_val(pte) &= ~_PAGE_PRESENT; > - } else > - VM_BUG_ON(1); > - return pte; > -} > - > #define ptep_set_numa ptep_set_numa > static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, > pte_t *ptep) > @@ -92,12 +60,6 @@ static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, > return; > } > > -#define pmd_numa pmd_numa > -static inline int pmd_numa(pmd_t pmd) > -{ > - return pte_numa(pmd_pte(pmd)); > -} > - > #define pmdp_set_numa pmdp_set_numa > static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > pmd_t *pmdp) > @@ -109,16 +71,21 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > return; > } > > -#define pmd_mknonnuma pmd_mknonnuma > -static inline pmd_t pmd_mknonnuma(pmd_t pmd) > +/* > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist > + * which was inherited from x86. For the purposes of powerpc pte_basic_t and > + * pmd_t are equivalent > + */ > +#define pteval_t pte_basic_t > +#define pmdval_t pmd_t > +static inline pteval_t ptenuma_flags(pte_t pte) > { > - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); > + return pte_val(pte) & _PAGE_NUMA_MASK; > } > > -#define pmd_mknuma pmd_mknuma > -static inline pmd_t pmd_mknuma(pmd_t pmd) > +static inline pmdval_t pmdnuma_flags(pte_t pte) > { > - return pte_pmd(pte_mknuma(pmd_pte(pmd))); > + return pmd_val(pte) & _PAGE_NUMA_MASK; > } > > # else .... > --- a/include/asm-generic/pgtable.h > +++ b/include/asm-generic/pgtable.h > @@ -660,11 +660,12 @@ static inline int pmd_trans_unstable(pmd_t *pmd) > } > > #ifdef CONFIG_NUMA_BALANCING > -#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE > /* > - * _PAGE_NUMA works identical to _PAGE_PROTNONE (it's actually the > - * same bit too). It's set only when _PAGE_PRESET is not set and it's > - * never set if _PAGE_PRESENT is set. > + * _PAGE_NUMA distinguishes between an unmapped page table entry, an entry that > + * is protected for PROT_NONE and a NUMA hinting fault entry. If the > + * architecture defines __PAGE_PROTNONE then it should take that into account > + * but those that do not can rely on the fact that the NUMA hinting scanner > + * skips inaccessible VMAs. > * > * pte/pmd_present() returns true if pte/pmd_numa returns true. Page > * fault triggers on those regions if pte/pmd_numa returns true > @@ -673,16 +674,14 @@ static inline int pmd_trans_unstable(pmd_t *pmd) > #ifndef pte_numa > static inline int pte_numa(pte_t pte) > { > - return (pte_flags(pte) & > - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; > + return (ptenuma_flags(pte) & _PAGE_NUMA_MASK) == _PAGE_NUMA; > } Can we avoid & _PAGE_NUMA_MASK ?. I understand that you need that for x86 because you have #define ptenuma_flags pte_flags But on ppc64 you already have static inline pteval_t ptenuma_flags(pte_t pte) { return pte_val(pte) & _PAGE_NUMA_MASK; } -aneesh ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: mm: BUG in unmap_page_range @ 2014-08-07 8:40 ` Aneesh Kumar K.V 0 siblings, 0 replies; 86+ messages in thread From: Aneesh Kumar K.V @ 2014-08-07 8:40 UTC (permalink / raw) To: Mel Gorman Cc: Hugh Dickins, Sasha Levin, linux-mm, Andrew Morton, Dave Jones, LKML, Kirill A. Shutemov, Peter Zijlstra, Rik van Riel, Johannes Weiner, Cyrill Gorcunov, linuxppc-dev Mel Gorman <mgorman@suse.de> writes: > On Wed, Aug 06, 2014 at 12:44:45PM +0530, Aneesh Kumar K.V wrote: >> > -#define pmd_mknonnuma pmd_mknonnuma >> > -static inline pmd_t pmd_mknonnuma(pmd_t pmd) >> > +/* >> > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist >> > + * which was inherited from x86. For the purposes of powerpc pte_basic_t is >> > + * equivalent >> > + */ >> > +#define pteval_t pte_basic_t >> > +#define pmdval_t pmd_t >> > +static inline pteval_t pte_flags(pte_t pte) >> > { >> > - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); >> > + return pte_val(pte) & PAGE_PROT_BITS; >> >> PAGE_PROT_BITS don't get the _PAGE_NUMA and _PAGE_PRESENT. I will have >> to check further to find out why the mask doesn't include >> _PAGE_PRESENT. >> > > Dumb of me, not sure how I managed that. For the purposes of what is required > it doesn't matter what PAGE_PROT_BITS does. It is clearer if there is a mask > that defines what bits are of interest to the generic helpers which is what > this version attempts to do. It's not tested on powerpc at all > unfortunately. Boot tested on ppc64. # grep numa /proc/vmstat numa_hit 156722 numa_miss 0 numa_foreign 0 numa_interleave 6365 numa_local 153457 numa_other 3265 numa_pte_updates 169 numa_huge_pte_updates 0 numa_hint_faults 150 numa_hint_faults_local 138 numa_pages_migrated 10 > > ---8<--- > mm: Remove misleading ARCH_USES_NUMA_PROT_NONE > > ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented > _PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and > relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting > fault scanner. This was found to be conceptually confusing with a lot of > implicit assumptions and it was asked that an alternative be found. > > Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the > PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap > PTE bits and shrunk the maximum possible swap size but it did not go far > enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA > but the relics still exist. > > This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary > duplication in powerpc vs the generic implementation by defining the types > the core NUMA helpers expected to exist from x86 with their ppc64 equivalent. > This necessitated that a PTE bit mask be created that identified the bits > that distinguish present from NUMA pte entries but it is expected this > will only differ between arches based on _PAGE_PROTNONE. The naming for > the generic helpers was taken from x86 originally but ppc64 has types that > are equivalent for the purposes of the helper so they are mapped instead > of duplicating code. > > Signed-off-by: Mel Gorman <mgorman@suse.de> > --- > arch/powerpc/include/asm/pgtable.h | 57 ++++++++--------------------------- > arch/powerpc/include/asm/pte-common.h | 5 +++ > arch/x86/Kconfig | 1 - > arch/x86/include/asm/pgtable_types.h | 7 +++++ > include/asm-generic/pgtable.h | 27 ++++++----------- > init/Kconfig | 11 ------- > 6 files changed, 33 insertions(+), 75 deletions(-) > > diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h > index d98c1ec..beeb09e 100644 > --- a/arch/powerpc/include/asm/pgtable.h > +++ b/arch/powerpc/include/asm/pgtable.h > @@ -38,10 +38,9 @@ static inline int pte_none(pte_t pte) { return (pte_val(pte) & ~_PTE_NONE_MASK) > static inline pgprot_t pte_pgprot(pte_t pte) { return __pgprot(pte_val(pte) & PAGE_PROT_BITS); } > > #ifdef CONFIG_NUMA_BALANCING > - > static inline int pte_present(pte_t pte) > { > - return pte_val(pte) & (_PAGE_PRESENT | _PAGE_NUMA); > + return pte_val(pte) & _PAGE_NUMA_MASK; > } > > #define pte_present_nonuma pte_present_nonuma > @@ -50,37 +49,6 @@ static inline int pte_present_nonuma(pte_t pte) > return pte_val(pte) & (_PAGE_PRESENT); > } > > -#define pte_numa pte_numa > -static inline int pte_numa(pte_t pte) > -{ > - return (pte_val(pte) & > - (_PAGE_NUMA|_PAGE_PRESENT)) == _PAGE_NUMA; > -} > - > -#define pte_mknonnuma pte_mknonnuma > -static inline pte_t pte_mknonnuma(pte_t pte) > -{ > - pte_val(pte) &= ~_PAGE_NUMA; > - pte_val(pte) |= _PAGE_PRESENT | _PAGE_ACCESSED; > - return pte; > -} > - > -#define pte_mknuma pte_mknuma > -static inline pte_t pte_mknuma(pte_t pte) > -{ > - /* > - * We should not set _PAGE_NUMA on non present ptes. Also clear the > - * present bit so that hash_page will return 1 and we collect this > - * as numa fault. > - */ > - if (pte_present(pte)) { > - pte_val(pte) |= _PAGE_NUMA; > - pte_val(pte) &= ~_PAGE_PRESENT; > - } else > - VM_BUG_ON(1); > - return pte; > -} > - > #define ptep_set_numa ptep_set_numa > static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, > pte_t *ptep) > @@ -92,12 +60,6 @@ static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr, > return; > } > > -#define pmd_numa pmd_numa > -static inline int pmd_numa(pmd_t pmd) > -{ > - return pte_numa(pmd_pte(pmd)); > -} > - > #define pmdp_set_numa pmdp_set_numa > static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > pmd_t *pmdp) > @@ -109,16 +71,21 @@ static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr, > return; > } > > -#define pmd_mknonnuma pmd_mknonnuma > -static inline pmd_t pmd_mknonnuma(pmd_t pmd) > +/* > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist > + * which was inherited from x86. For the purposes of powerpc pte_basic_t and > + * pmd_t are equivalent > + */ > +#define pteval_t pte_basic_t > +#define pmdval_t pmd_t > +static inline pteval_t ptenuma_flags(pte_t pte) > { > - return pte_pmd(pte_mknonnuma(pmd_pte(pmd))); > + return pte_val(pte) & _PAGE_NUMA_MASK; > } > > -#define pmd_mknuma pmd_mknuma > -static inline pmd_t pmd_mknuma(pmd_t pmd) > +static inline pmdval_t pmdnuma_flags(pte_t pte) > { > - return pte_pmd(pte_mknuma(pmd_pte(pmd))); > + return pmd_val(pte) & _PAGE_NUMA_MASK; > } > > # else .... > --- a/include/asm-generic/pgtable.h > +++ b/include/asm-generic/pgtable.h > @@ -660,11 +660,12 @@ static inline int pmd_trans_unstable(pmd_t *pmd) > } > > #ifdef CONFIG_NUMA_BALANCING > -#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE > /* > - * _PAGE_NUMA works identical to _PAGE_PROTNONE (it's actually the > - * same bit too). It's set only when _PAGE_PRESET is not set and it's > - * never set if _PAGE_PRESENT is set. > + * _PAGE_NUMA distinguishes between an unmapped page table entry, an entry that > + * is protected for PROT_NONE and a NUMA hinting fault entry. If the > + * architecture defines __PAGE_PROTNONE then it should take that into account > + * but those that do not can rely on the fact that the NUMA hinting scanner > + * skips inaccessible VMAs. > * > * pte/pmd_present() returns true if pte/pmd_numa returns true. Page > * fault triggers on those regions if pte/pmd_numa returns true > @@ -673,16 +674,14 @@ static inline int pmd_trans_unstable(pmd_t *pmd) > #ifndef pte_numa > static inline int pte_numa(pte_t pte) > { > - return (pte_flags(pte) & > - (_PAGE_NUMA|_PAGE_PROTNONE|_PAGE_PRESENT)) == _PAGE_NUMA; > + return (ptenuma_flags(pte) & _PAGE_NUMA_MASK) == _PAGE_NUMA; > } Can we avoid & _PAGE_NUMA_MASK ?. I understand that you need that for x86 because you have #define ptenuma_flags pte_flags But on ppc64 you already have static inline pteval_t ptenuma_flags(pte_t pte) { return pte_val(pte) & _PAGE_NUMA_MASK; } -aneesh -- 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] 86+ messages in thread
end of thread, other threads:[~2014-09-17 21:38 UTC | newest] Thread overview: 86+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-08-02 21:58 mm: BUG in unmap_page_range Sasha Levin 2014-08-02 21:58 ` Sasha Levin 2014-08-04 11:40 ` Hugh Dickins 2014-08-04 11:40 ` Hugh Dickins 2014-08-05 14:44 ` Mel Gorman 2014-08-05 14:44 ` Mel Gorman 2014-08-06 0:42 ` Hugh Dickins 2014-08-06 0:42 ` Hugh Dickins 2014-08-06 1:04 ` Sasha Levin 2014-08-06 1:04 ` Sasha Levin 2014-08-12 3:28 ` Sasha Levin 2014-08-12 3:28 ` Sasha Levin 2014-08-12 10:47 ` [PATCH] x86,mm: fix pte_special versus pte_numa Mel Gorman 2014-08-12 10:47 ` Mel Gorman 2014-08-12 11:08 ` [PATCH] mm: Remove misleading ARCH_USES_NUMA_PROT_NONE Mel Gorman 2014-08-12 11:08 ` Mel Gorman 2014-08-13 13:14 ` Aneesh Kumar K.V 2014-08-13 13:14 ` Aneesh Kumar K.V 2014-08-27 3:16 ` mm: BUG in unmap_page_range Sasha Levin 2014-08-27 3:16 ` Sasha Levin 2014-08-27 15:26 ` Mel Gorman 2014-08-27 15:26 ` Mel Gorman 2014-08-27 18:21 ` Sasha Levin 2014-08-27 18:21 ` Sasha Levin 2014-08-30 1:23 ` Sasha Levin 2014-08-30 1:23 ` Sasha Levin 2014-09-04 9:04 ` Sasha Levin 2014-09-04 9:04 ` Sasha Levin 2014-09-08 17:18 ` Mel Gorman 2014-09-08 17:18 ` Mel Gorman 2014-09-08 17:23 ` Sasha Levin 2014-09-08 17:56 ` Sasha Levin 2014-09-08 17:56 ` Sasha Levin 2014-09-09 21:33 ` Mel Gorman 2014-09-09 21:33 ` Mel Gorman 2014-09-09 22:20 ` Sasha Levin 2014-09-09 22:20 ` Sasha Levin 2014-09-10 2:45 ` Hugh Dickins 2014-09-10 2:45 ` Hugh Dickins 2014-09-10 12:47 ` Mel Gorman 2014-09-10 12:47 ` Mel Gorman 2014-09-10 14:24 ` Trinity and mbind flags (WAS: Re: mm: BUG in unmap_page_range) Sasha Levin 2014-09-10 14:24 ` Sasha Levin 2014-09-10 14:33 ` Dave Jones 2014-09-10 14:33 ` Dave Jones 2014-09-10 19:06 ` mm: BUG in unmap_page_range Sasha Levin 2014-09-10 19:06 ` Sasha Levin 2014-09-10 19:36 ` Hugh Dickins 2014-09-10 19:36 ` Hugh Dickins 2014-09-11 2:43 ` Sasha Levin 2014-09-11 2:43 ` Sasha Levin 2014-09-11 11:39 ` Hugh Dickins 2014-09-11 11:39 ` Hugh Dickins 2014-09-11 14:22 ` Sasha Levin 2014-09-11 14:22 ` Sasha Levin 2014-09-11 14:33 ` Dave Jones 2014-09-11 14:33 ` Dave Jones 2014-09-11 16:28 ` Mel Gorman 2014-09-11 16:28 ` Mel Gorman 2014-09-11 22:38 ` Sasha Levin 2014-09-11 22:38 ` Sasha Levin 2014-09-17 21:37 ` Sasha Levin 2014-09-17 21:37 ` Sasha Levin 2014-09-10 13:12 ` Sasha Levin 2014-09-10 13:12 ` Sasha Levin 2014-09-10 13:40 ` Mel Gorman 2014-09-10 13:40 ` Mel Gorman 2014-09-10 16:44 ` Sasha Levin 2014-09-10 16:44 ` Sasha Levin 2014-09-10 19:09 ` Hugh Dickins 2014-09-10 19:09 ` Hugh Dickins 2014-09-10 20:36 ` Sasha Levin 2014-09-10 20:36 ` Sasha Levin 2014-09-10 23:00 ` Hugh Dickins 2014-09-10 23:00 ` Hugh Dickins 2014-08-06 10:35 ` Mel Gorman 2014-08-06 10:35 ` Mel Gorman 2014-08-06 7:14 ` Aneesh Kumar K.V 2014-08-06 7:14 ` Aneesh Kumar K.V 2014-08-06 7:14 ` Aneesh Kumar K.V 2014-08-06 10:23 ` Mel Gorman 2014-08-06 10:23 ` Mel Gorman 2014-08-06 10:23 ` Mel Gorman 2014-08-07 8:40 ` Aneesh Kumar K.V 2014-08-07 8:40 ` Aneesh Kumar K.V 2014-08-07 8:40 ` Aneesh Kumar K.V
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.