* Re: BUG: unable to handle kernel paging request in do_futex [not found] <001a113ed15ed79d14055f379011@google.com> @ 2017-12-14 15:31 ` Thomas Gleixner 2017-12-14 16:39 ` Andrey Ryabinin 0 siblings, 1 reply; 4+ messages in thread From: Thomas Gleixner @ 2017-12-14 15:31 UTC (permalink / raw) To: syzbot Cc: Darren Hart, LKML, Ingo Molnar, Peter Zijlstra, syzkaller-bugs, Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov On Thu, 30 Nov 2017, syzbot wrote: > Hello, > > syzkaller hit the following crash on 11fed7829beff10184503fd65e5919926464601a > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > > Unfortunately, I don't have any reproducer for this bug yet. > > > BUG: unable to handle kernel paging request at 00000000c314149f That's a user space address which is nowhere in the registers. Is that perhaps pre commit: 328b4ed93b69a ? > IP: arch_futex_atomic_op_inuser arch/x86/include/asm/futex.h:67 [inline] > IP: futex_atomic_op_inuser kernel/futex.c:1588 [inline] > IP: futex_wake_op kernel/futex.c:1637 [inline] > IP: do_futex+0x14c8/0x2280 kernel/futex.c:3483 > PGD 5e28067 P4D 5e28067 PUD 5e2a067 PMD 0 > Oops: 0002 [#1] SMP KASAN ^^^^ X86_PF_WRITE > Dumping ftrace buffer: > (ftrace buffer empty) > Modules linked in: > CPU: 0 PID: 14626 Comm: syz-executor6 Not tainted 4.15.0-rc1-next-20171130+ > #56 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google > 01/01/2011 > task: 000000005f17dad6 task.stack: 000000005af7607c > RIP: 0010:arch_futex_atomic_op_inuser arch/x86/include/asm/futex.h:67 [inline] > RIP: 0010:futex_atomic_op_inuser kernel/futex.c:1588 [inline] > RIP: 0010:futex_wake_op kernel/futex.c:1637 [inline] > RIP: 0010:do_futex+0x14c8/0x2280 kernel/futex.c:3483 > RSP: 0018:ffff8801cffafa18 EFLAGS: 00010246 > RAX: 000000007fffffff RBX: 0000000040000002 RCX: ffffffff8164e3d9 > RDX: 0000000000000000 RSI: ffffc900034e8000 RDI: 0000000000000000 > RBP: ffff8801cffafe38 R08: 1ffffffff0d31367 R09: 0000000000000004 > R10: 0000000000000000 R11: ffffffff8748cd60 R12: ffff8801d0f30180 > R13: 0000000020000000 R14: dffffc0000000000 R15: ffff8801cffafe10 > FS: 00007f66305e0700(0000) GS:ffff8801db400000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: fffffffffffffff8 CR3: 00000001ccc2e000 CR4: 00000000001426f0 ^^^^^^^^^^^^^^^^ is a totally different address so its either completely bogus or the above address is a hashed pointer because that printk used to be %p and was changed to %px in 328b4ed93b69a > DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff3 DR7: 0000000000bb060a > Call Trace: > SYSC_futex kernel/futex.c:3533 [inline] > SyS_futex+0x260/0x390 kernel/futex.c:3501 > entry_SYSCALL_64_fastpath+0x1f/0x96 > RIP: 0033:0x4529d9 > RSP: 002b:00007f66305dfc58 EFLAGS: 00000212 ORIG_RAX: 00000000000000ca > RAX: ffffffffffffffda RBX: 00007f66305e0700 RCX: 00000000004529d9 > RDX: 0000000000000007 RSI: 0000000000000085 RDI: 0000000020062000 > RBP: 0000000000000000 R08: 0000000020000000 R09: 0000000040000002 > R10: 000000002085fff0 R11: 0000000000000212 R12: 0000000000000000 > R13: 0000000000a6f7ff R14: 00007f66305e09c0 R15: 0000000000000000 The arguments are: RDI uaddr 0000000020062000 RSI op 0000000000000085 RDX val 0000000000000007 RCX utime 00000000004529d9 R8 uaddr2 0000000020000000 R9 val2 0000000040000002 > Code: 31 d2 0f 1f 00 45 87 65 00 0f 1f 00 89 95 30 fc ff ff e9 1d ff ff ff e8 > 67 56 0b 00 31 d2 8b bd 00 fc ff ff 0f 1f 00 41 8b 45 00 <89> c1 31 f9 f0 41 > 0f b1 4d 00 75 f0 0f 1f 00 41 89 c4 89 95 30 and the code is: 27: 41 8b 45 00 mov 0x0(%r13),%eax 2b:* 89 c1 mov %eax,%ecx <-- trapping instruction 2d: 31 f9 xor %edi,%ecx 2f: f0 41 0f b1 4d 00 lock cmpxchg %ecx,0x0(%r13) 35: 75 f0 jne 0x27 The trapping instruction cannot trap :). Assumed it's the move before that, then the accessed location is R13 + 0 = 0000000020000000, which is uaddr2 and entirely correct. And what I completely fail to understand why this triggers at all. That code section is guarded by an extable fixup so this should never come in. Is this a KASAN artifact? Thanks, tglx ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: BUG: unable to handle kernel paging request in do_futex 2017-12-14 15:31 ` BUG: unable to handle kernel paging request in do_futex Thomas Gleixner @ 2017-12-14 16:39 ` Andrey Ryabinin 2017-12-14 17:02 ` Thomas Gleixner 0 siblings, 1 reply; 4+ messages in thread From: Andrey Ryabinin @ 2017-12-14 16:39 UTC (permalink / raw) To: Thomas Gleixner, syzbot Cc: Darren Hart, LKML, Ingo Molnar, Peter Zijlstra, syzkaller-bugs, Alexander Potapenko, Dmitry Vyukov On 12/14/2017 06:31 PM, Thomas Gleixner wrote: > On Thu, 30 Nov 2017, syzbot wrote: >> Hello, >> >> syzkaller hit the following crash on 11fed7829beff10184503fd65e5919926464601a >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master >> compiler: gcc (GCC) 7.1.1 20170620 >> .config is attached >> Raw console output is attached. >> >> Unfortunately, I don't have any reproducer for this bug yet. >> >> >> BUG: unable to handle kernel paging request at 00000000c314149f > > That's a user space address which is nowhere in the registers. Is that > perhaps pre commit: 328b4ed93b69a ? Seems so. Kernel version is 4.15.0-rc1-next-20171130+ it shouldn't have that commit. >> IP: arch_futex_atomic_op_inuser arch/x86/include/asm/futex.h:67 [inline] >> IP: futex_atomic_op_inuser kernel/futex.c:1588 [inline] >> IP: futex_wake_op kernel/futex.c:1637 [inline] >> IP: do_futex+0x14c8/0x2280 kernel/futex.c:3483 >> PGD 5e28067 P4D 5e28067 PUD 5e2a067 PMD 0 >> Oops: 0002 [#1] SMP KASAN > > ^^^^ X86_PF_WRITE > >> Dumping ftrace buffer: >> (ftrace buffer empty) >> Modules linked in: >> CPU: 0 PID: 14626 Comm: syz-executor6 Not tainted 4.15.0-rc1-next-20171130+ >> #56 >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google >> 01/01/2011 >> task: 000000005f17dad6 task.stack: 000000005af7607c >> RIP: 0010:arch_futex_atomic_op_inuser arch/x86/include/asm/futex.h:67 [inline] >> RIP: 0010:futex_atomic_op_inuser kernel/futex.c:1588 [inline] >> RIP: 0010:futex_wake_op kernel/futex.c:1637 [inline] >> RIP: 0010:do_futex+0x14c8/0x2280 kernel/futex.c:3483 >> RSP: 0018:ffff8801cffafa18 EFLAGS: 00010246 >> RAX: 000000007fffffff RBX: 0000000040000002 RCX: ffffffff8164e3d9 >> RDX: 0000000000000000 RSI: ffffc900034e8000 RDI: 0000000000000000 >> RBP: ffff8801cffafe38 R08: 1ffffffff0d31367 R09: 0000000000000004 >> R10: 0000000000000000 R11: ffffffff8748cd60 R12: ffff8801d0f30180 >> R13: 0000000020000000 R14: dffffc0000000000 R15: ffff8801cffafe10 >> FS: 00007f66305e0700(0000) GS:ffff8801db400000(0000) knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> CR2: fffffffffffffff8 CR3: 00000001ccc2e000 CR4: 00000000001426f0 > > ^^^^^^^^^^^^^^^^ is a totally different address so its either > completely bogus or the above address is a hashed pointer because > that printk used to be %p and was changed to %px in 328b4ed93b69a > >> DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000 >> DR3: 0000000000000000 DR6: 00000000ffff0ff3 DR7: 0000000000bb060a >> Call Trace: >> SYSC_futex kernel/futex.c:3533 [inline] >> SyS_futex+0x260/0x390 kernel/futex.c:3501 >> entry_SYSCALL_64_fastpath+0x1f/0x96 >> RIP: 0033:0x4529d9 >> RSP: 002b:00007f66305dfc58 EFLAGS: 00000212 ORIG_RAX: 00000000000000ca >> RAX: ffffffffffffffda RBX: 00007f66305e0700 RCX: 00000000004529d9 >> RDX: 0000000000000007 RSI: 0000000000000085 RDI: 0000000020062000 >> RBP: 0000000000000000 R08: 0000000020000000 R09: 0000000040000002 >> R10: 000000002085fff0 R11: 0000000000000212 R12: 0000000000000000 >> R13: 0000000000a6f7ff R14: 00007f66305e09c0 R15: 0000000000000000 > > The arguments are: > > RDI uaddr 0000000020062000 > RSI op 0000000000000085 > RDX val 0000000000000007 > RCX utime 00000000004529d9 > R8 uaddr2 0000000020000000 > R9 val2 0000000040000002 > >> Code: 31 d2 0f 1f 00 45 87 65 00 0f 1f 00 89 95 30 fc ff ff e9 1d ff ff ff e8 >> 67 56 0b 00 31 d2 8b bd 00 fc ff ff 0f 1f 00 41 8b 45 00 <89> c1 31 f9 f0 41 >> 0f b1 4d 00 75 f0 0f 1f 00 41 89 c4 89 95 30 > > and the code is: > > 27: 41 8b 45 00 mov 0x0(%r13),%eax > 2b:* 89 c1 mov %eax,%ecx <-- trapping instruction > 2d: 31 f9 xor %edi,%ecx > 2f: f0 41 0f b1 4d 00 lock cmpxchg %ecx,0x0(%r13) > 35: 75 f0 jne 0x27 > > The trapping instruction cannot trap :). Assumed it's the move before that, > then the accessed location is R13 + 0 = 0000000020000000, which is uaddr2 > and entirely correct. > But fault address must be 0xfffffffffffffff8 as per CR2, so it can't be 'mov 0x0(%r13),%eax' either. Right? > And what I completely fail to understand why this triggers at all. That > code section is guarded by an extable fixup so this should never come in. > > Is this a KASAN artifact? > I don't see any evidence for KASAN being involved here. > Thanks, > > tglx > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: BUG: unable to handle kernel paging request in do_futex 2017-12-14 16:39 ` Andrey Ryabinin @ 2017-12-14 17:02 ` Thomas Gleixner 2017-12-19 12:12 ` Dmitry Vyukov 0 siblings, 1 reply; 4+ messages in thread From: Thomas Gleixner @ 2017-12-14 17:02 UTC (permalink / raw) To: Andrey Ryabinin Cc: syzbot, Darren Hart, LKML, Ingo Molnar, Peter Zijlstra, syzkaller-bugs, Alexander Potapenko, Dmitry Vyukov On Thu, 14 Dec 2017, Andrey Ryabinin wrote: > On 12/14/2017 06:31 PM, Thomas Gleixner wrote: > > On Thu, 30 Nov 2017, syzbot wrote: > >> BUG: unable to handle kernel paging request at 00000000c314149f > > > > That's a user space address which is nowhere in the registers. Is that > > perhaps pre commit: 328b4ed93b69a ? > > Seems so. Kernel version is 4.15.0-rc1-next-20171130+ it shouldn't have that commit. > > >> IP: arch_futex_atomic_op_inuser arch/x86/include/asm/futex.h:67 [inline] > >> IP: futex_atomic_op_inuser kernel/futex.c:1588 [inline] > >> IP: futex_wake_op kernel/futex.c:1637 [inline] > >> IP: do_futex+0x14c8/0x2280 kernel/futex.c:3483 > >> PGD 5e28067 P4D 5e28067 PUD 5e2a067 PMD 0 > >> Oops: 0002 [#1] SMP KASAN > > > > ^^^^ X86_PF_WRITE > > > >> Dumping ftrace buffer: > >> (ftrace buffer empty) > >> Modules linked in: > >> CPU: 0 PID: 14626 Comm: syz-executor6 Not tainted 4.15.0-rc1-next-20171130+ > >> #56 > >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google > >> 01/01/2011 > >> task: 000000005f17dad6 task.stack: 000000005af7607c > >> RIP: 0010:arch_futex_atomic_op_inuser arch/x86/include/asm/futex.h:67 [inline] > >> RIP: 0010:futex_atomic_op_inuser kernel/futex.c:1588 [inline] > >> RIP: 0010:futex_wake_op kernel/futex.c:1637 [inline] > >> RIP: 0010:do_futex+0x14c8/0x2280 kernel/futex.c:3483 > >> RSP: 0018:ffff8801cffafa18 EFLAGS: 00010246 > >> RAX: 000000007fffffff RBX: 0000000040000002 RCX: ffffffff8164e3d9 > >> RDX: 0000000000000000 RSI: ffffc900034e8000 RDI: 0000000000000000 > >> RBP: ffff8801cffafe38 R08: 1ffffffff0d31367 R09: 0000000000000004 > >> R10: 0000000000000000 R11: ffffffff8748cd60 R12: ffff8801d0f30180 > >> R13: 0000000020000000 R14: dffffc0000000000 R15: ffff8801cffafe10 > >> FS: 00007f66305e0700(0000) GS:ffff8801db400000(0000) knlGS:0000000000000000 > >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > >> CR2: fffffffffffffff8 CR3: 00000001ccc2e000 CR4: 00000000001426f0 > > > > ^^^^^^^^^^^^^^^^ is a totally different address so its either > > completely bogus or the above address is a hashed pointer because > > that printk used to be %p and was changed to %px in 328b4ed93b69a > > > >> DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000 > >> DR3: 0000000000000000 DR6: 00000000ffff0ff3 DR7: 0000000000bb060a > >> Call Trace: > >> SYSC_futex kernel/futex.c:3533 [inline] > >> SyS_futex+0x260/0x390 kernel/futex.c:3501 > >> entry_SYSCALL_64_fastpath+0x1f/0x96 > >> RIP: 0033:0x4529d9 > >> RSP: 002b:00007f66305dfc58 EFLAGS: 00000212 ORIG_RAX: 00000000000000ca > >> RAX: ffffffffffffffda RBX: 00007f66305e0700 RCX: 00000000004529d9 > >> RDX: 0000000000000007 RSI: 0000000000000085 RDI: 0000000020062000 > >> RBP: 0000000000000000 R08: 0000000020000000 R09: 0000000040000002 > >> R10: 000000002085fff0 R11: 0000000000000212 R12: 0000000000000000 > >> R13: 0000000000a6f7ff R14: 00007f66305e09c0 R15: 0000000000000000 > > > > The arguments are: > > > > RDI uaddr 0000000020062000 > > RSI op 0000000000000085 > > RDX val 0000000000000007 > > RCX utime 00000000004529d9 > > R8 uaddr2 0000000020000000 > > R9 val2 0000000040000002 > > > >> Code: 31 d2 0f 1f 00 45 87 65 00 0f 1f 00 89 95 30 fc ff ff e9 1d ff ff ff e8 > >> 67 56 0b 00 31 d2 8b bd 00 fc ff ff 0f 1f 00 41 8b 45 00 <89> c1 31 f9 f0 41 > >> 0f b1 4d 00 75 f0 0f 1f 00 41 89 c4 89 95 30 > > > > and the code is: > > > > 27: 41 8b 45 00 mov 0x0(%r13),%eax > > 2b:* 89 c1 mov %eax,%ecx <-- trapping instruction > > 2d: 31 f9 xor %edi,%ecx > > 2f: f0 41 0f b1 4d 00 lock cmpxchg %ecx,0x0(%r13) > > 35: 75 f0 jne 0x27 > > > > The trapping instruction cannot trap :). Assumed it's the move before that, > > then the accessed location is R13 + 0 = 0000000020000000, which is uaddr2 > > and entirely correct. > > > But fault address must be 0xfffffffffffffff8 as per CR2, so it can't be > 'mov 0x0(%r13),%eax' either. Right? Indeed > > And what I completely fail to understand why this triggers at all. That > > code section is guarded by an extable fixup so this should never come in. > > > > Is this a KASAN artifact? > > > I don't see any evidence for KASAN being involved here. I was just asking because of: >> Oops: 0002 [#1] SMP KASAN Thanks, tglx ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: BUG: unable to handle kernel paging request in do_futex 2017-12-14 17:02 ` Thomas Gleixner @ 2017-12-19 12:12 ` Dmitry Vyukov 0 siblings, 0 replies; 4+ messages in thread From: Dmitry Vyukov @ 2017-12-19 12:12 UTC (permalink / raw) To: Thomas Gleixner Cc: Andrey Ryabinin, syzbot, Darren Hart, LKML, Ingo Molnar, Peter Zijlstra, syzkaller-bugs, Alexander Potapenko On Thu, Dec 14, 2017 at 6:02 PM, Thomas Gleixner <tglx@linutronix.de> wrote: > On Thu, 14 Dec 2017, Andrey Ryabinin wrote: >> On 12/14/2017 06:31 PM, Thomas Gleixner wrote: >> > On Thu, 30 Nov 2017, syzbot wrote: >> >> BUG: unable to handle kernel paging request at 00000000c314149f >> > >> > That's a user space address which is nowhere in the registers. Is that >> > perhaps pre commit: 328b4ed93b69a ? >> >> Seems so. Kernel version is 4.15.0-rc1-next-20171130+ it shouldn't have that commit. >> >> >> IP: arch_futex_atomic_op_inuser arch/x86/include/asm/futex.h:67 [inline] >> >> IP: futex_atomic_op_inuser kernel/futex.c:1588 [inline] >> >> IP: futex_wake_op kernel/futex.c:1637 [inline] >> >> IP: do_futex+0x14c8/0x2280 kernel/futex.c:3483 >> >> PGD 5e28067 P4D 5e28067 PUD 5e2a067 PMD 0 >> >> Oops: 0002 [#1] SMP KASAN >> > >> > ^^^^ X86_PF_WRITE >> > >> >> Dumping ftrace buffer: >> >> (ftrace buffer empty) >> >> Modules linked in: >> >> CPU: 0 PID: 14626 Comm: syz-executor6 Not tainted 4.15.0-rc1-next-20171130+ >> >> #56 >> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google >> >> 01/01/2011 >> >> task: 000000005f17dad6 task.stack: 000000005af7607c >> >> RIP: 0010:arch_futex_atomic_op_inuser arch/x86/include/asm/futex.h:67 [inline] >> >> RIP: 0010:futex_atomic_op_inuser kernel/futex.c:1588 [inline] >> >> RIP: 0010:futex_wake_op kernel/futex.c:1637 [inline] >> >> RIP: 0010:do_futex+0x14c8/0x2280 kernel/futex.c:3483 >> >> RSP: 0018:ffff8801cffafa18 EFLAGS: 00010246 >> >> RAX: 000000007fffffff RBX: 0000000040000002 RCX: ffffffff8164e3d9 >> >> RDX: 0000000000000000 RSI: ffffc900034e8000 RDI: 0000000000000000 >> >> RBP: ffff8801cffafe38 R08: 1ffffffff0d31367 R09: 0000000000000004 >> >> R10: 0000000000000000 R11: ffffffff8748cd60 R12: ffff8801d0f30180 >> >> R13: 0000000020000000 R14: dffffc0000000000 R15: ffff8801cffafe10 >> >> FS: 00007f66305e0700(0000) GS:ffff8801db400000(0000) knlGS:0000000000000000 >> >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> >> CR2: fffffffffffffff8 CR3: 00000001ccc2e000 CR4: 00000000001426f0 >> > >> > ^^^^^^^^^^^^^^^^ is a totally different address so its either >> > completely bogus or the above address is a hashed pointer because >> > that printk used to be %p and was changed to %px in 328b4ed93b69a >> > >> >> DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000 >> >> DR3: 0000000000000000 DR6: 00000000ffff0ff3 DR7: 0000000000bb060a >> >> Call Trace: >> >> SYSC_futex kernel/futex.c:3533 [inline] >> >> SyS_futex+0x260/0x390 kernel/futex.c:3501 >> >> entry_SYSCALL_64_fastpath+0x1f/0x96 >> >> RIP: 0033:0x4529d9 >> >> RSP: 002b:00007f66305dfc58 EFLAGS: 00000212 ORIG_RAX: 00000000000000ca >> >> RAX: ffffffffffffffda RBX: 00007f66305e0700 RCX: 00000000004529d9 >> >> RDX: 0000000000000007 RSI: 0000000000000085 RDI: 0000000020062000 >> >> RBP: 0000000000000000 R08: 0000000020000000 R09: 0000000040000002 >> >> R10: 000000002085fff0 R11: 0000000000000212 R12: 0000000000000000 >> >> R13: 0000000000a6f7ff R14: 00007f66305e09c0 R15: 0000000000000000 >> > >> > The arguments are: >> > >> > RDI uaddr 0000000020062000 >> > RSI op 0000000000000085 >> > RDX val 0000000000000007 >> > RCX utime 00000000004529d9 >> > R8 uaddr2 0000000020000000 >> > R9 val2 0000000040000002 >> > >> >> Code: 31 d2 0f 1f 00 45 87 65 00 0f 1f 00 89 95 30 fc ff ff e9 1d ff ff ff e8 >> >> 67 56 0b 00 31 d2 8b bd 00 fc ff ff 0f 1f 00 41 8b 45 00 <89> c1 31 f9 f0 41 >> >> 0f b1 4d 00 75 f0 0f 1f 00 41 89 c4 89 95 30 >> > >> > and the code is: >> > >> > 27: 41 8b 45 00 mov 0x0(%r13),%eax >> > 2b:* 89 c1 mov %eax,%ecx <-- trapping instruction >> > 2d: 31 f9 xor %edi,%ecx >> > 2f: f0 41 0f b1 4d 00 lock cmpxchg %ecx,0x0(%r13) >> > 35: 75 f0 jne 0x27 >> > >> > The trapping instruction cannot trap :). Assumed it's the move before that, >> > then the accessed location is R13 + 0 = 0000000020000000, which is uaddr2 >> > and entirely correct. >> > >> But fault address must be 0xfffffffffffffff8 as per CR2, so it can't be >> 'mov 0x0(%r13),%eax' either. Right? > > Indeed > >> > And what I completely fail to understand why this triggers at all. That >> > code section is guarded by an extable fixup so this should never come in. >> > >> > Is this a KASAN artifact? >> > >> I don't see any evidence for KASAN being involved here. > > I was just asking because of: > >>> Oops: 0002 [#1] SMP KASAN #syz dup: BUG: unable to handle kernel paging request in __switch_to ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-12-19 12:13 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <001a113ed15ed79d14055f379011@google.com>
2017-12-14 15:31 ` BUG: unable to handle kernel paging request in do_futex Thomas Gleixner
2017-12-14 16:39 ` Andrey Ryabinin
2017-12-14 17:02 ` Thomas Gleixner
2017-12-19 12:12 ` Dmitry Vyukov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®