kernel panic: kProc-ful Page Fault in trhe Kernel at ADDR!oc-ful Page Fault in the Kernel

0 views
Skip to first unread message

syzbot

unread,
Jul 18, 2018, 2:00:04 PM7/18/18
to aka...@googlegroups.com
Hello,

syzbot found the following crash on:

HEAD commit: bf9a9ba0d6af Add panic_hwtf() for kernel faults
git tree: https://github.com/akaros/akaros.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=14005c44400000
kernel config: https://syzkaller.appspot.com/x/.config?x=efef8cf2939304d3
dashboard link: https://syzkaller.appspot.com/bug?extid=b9f081311d55086e9f17
compiler:

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b9f081...@syzkaller.appspotmail.com

kernel panic at kern/arch/x86/trap.c:309, from core 3: kProc-ful Page Fault
in trhe Kernel at 0x00007f7fffad6bc0!oc-ful Page Fault in the Kernel
HW TRAP frame at 00xfffffff0000cdcc0 on core 3
rax 0x00007f7fffa01200
o rbx 0x00000000000d4d40
n rcx 0xffff core 3
fffad6bc0!kerne8l] 0safe! (tVoo crdx 0xfffffff00r0d0cx ddf00xff
big?)
fffff0000cddf0
[ rbp 0 rbp 0xfffffff0000cdd88
fe! (too big?)
xfffffff0000cdd88
rsi 0x00007f7fffad6bc0
rdi 0xffff80000217fd00
r8 0x0000000000000000
r9 0x0000000000000000
r10 0x000010000000a4c0
r11 0x0000000000000206
r12 0xffff80000217fd00
r13 0xffff80000217fd00
r14 0xfffffff0000cddf0
r15 0x0000000000000000
trap 0x0000000e Page Fault
gsbs 0xffffffffc8668140
fsbs 0x0000000000000000
err 0x--------00000000
rip 0xffffffffc2007019
cs 0x------------0008
flag 0x0000000000010286
rsp 0xfffffff0000cdd88
ss 0x------------0010
Backtrace of kernel context on Core 3:
#01 [<0xffffffffc2007019>] in post_ev_msg.isra.1 at src/event.c:82
#02 [< [inline] >] in post_vc_msg at src/event.c:106
#02 [<0xffffffffc2007896>] in post_vcore_event at src/event.c:489
#03 [<0xffffffffc20571c2>] in sys_self_notify at src/syscall.c:1506
#04 [<0xffffffffc20593c9>] in syscall at src/syscall.c:2528
#05 [<0xffffffffc2059584>] in run_local_syscall at src/syscall.c:2563
#06 [<0xffffffffc2059ab9>] in prep_syscalls at src/syscall.c:2583
#07 [<0xffffffffc20ab29a>] in sysenter_callwrapper at arch/x86/trap.c:851


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.

Barret Rhoden

unread,
Jul 18, 2018, 2:13:19 PM7/18/18
to aka...@googlegroups.com
On 2018-07-18 at 11:00 syzbot
<syzbot+b9f081...@syzkaller.appspotmail.com> wrote:
> dashboard link: https://syzkaller.appspot.com/bug?extid=b9f081311d55086e9f17

> kernel panic at kern/arch/x86/trap.c:309, from core 3: kProc-ful Page Fault
> in trhe Kernel at 0x00007f7fffad6bc0!oc-ful Page Fault in the Kernel
> HW TRAP frame at 00xfffffff0000cdcc0 on core 3
> rax 0x00007f7fffa01200
> o rbx 0x00000000000d4d40

I looked at the log for this one to see why it was garbled. It looks
like it called "prov -s", which triggers a bunch of kernel printks.
The other thing was the printk from kern/src/event.c@408. I think that
was a diagnostic printk.

Regular printks aren't serialized w.r.t. the panics. I'll think about
how to fix this.

Barret


Dmitry Vyukov

unread,
Jul 18, 2018, 3:15:41 PM7/18/18
to Barret Rhoden, aka...@googlegroups.com
FWIW fuchsia stop all cores on panic. I don't know how easy it is
doable in akaros, but maybe the simplest option to solve this once and
for all. Can be under debug config if necessary.
As I mentioned before, linux simply relies on single-printk atomicity.

Barret Rhoden

unread,
Jul 18, 2018, 3:54:03 PM7/18/18
to Dmitry Vyukov, aka...@googlegroups.com
On 2018-07-18 at 21:15 Dmitry Vyukov <dvy...@google.com> wrote:
> As I mentioned before, linux simply relies on single-printk atomicity.

Now that I think about it, I thought we had this, and that the problem
was prints that weren't for a full line. But looking at the exact
output, that's not the case.

Looking closer, I turned that "output_lock" off for kernel faults. The
reason at the time was to avoid deadlocks caused by faults in the
printf handler. I can sort that out with something like a recursive
lock.

Thanks,

Barret

Barret Rhoden

unread,
Jul 19, 2018, 4:31:59 PM7/19/18
to syzbot, aka...@googlegroups.com
On 2018-07-18 at 11:00 syzbot
<syzbot+b9f081...@syzkaller.appspotmail.com> wrote:
#syz invalid
Reply all
Reply to author
Forward
0 new messages