* 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-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: 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
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
(?)
@ 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: 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
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 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-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: 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
* 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-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
* 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
* 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 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 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 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 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: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-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
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.