Date: Mon, 06 Oct 2014 21:39:00 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: freebsd-net <freebsd-net@FreeBSD.org> Subject: page fault in unp_gc -> unp_accessable Message-ID: <5432E1C4.6090209@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
First, I think that this panic could be related to a crash of chromium process
that preceded it. Perhaps the crash triggered closing of sockets and that
interacted badly with unp_gc code.
Unread portion of the kernel message buffer:
<6>pid 48502 (chrome), uid 1001: exited on signal 11 (core dumped)
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x100000021
fault code = supervisor read data, page not present
...
(kgdb) bt
#0 doadump (textdump=1) at pcpu.h:223
#1 0xffffffff8063d9fd in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:445
#2 0xffffffff8063df3f in panic (fmt=<value optimized out>) at
/usr/src/sys/kern/kern_shutdown.c:621
#3 0xffffffff80861f4f in trap_fatal (frame=<value optimized out>, eva=<value
optimized out>) at /usr/src/sys/amd64/amd64/trap.c:866
#4 0xffffffff8086229c in trap_pfault (frame=0xfffffe01dd5d89e0, usermode=<value
optimized out>) at /usr/src/sys/amd64/amd64/trap.c:677
#5 0xffffffff808618be in trap (frame=0xfffffe01dd5d89e0) at
/usr/src/sys/amd64/amd64/trap.c:426
#6 0xffffffff808623f7 in trap_check (frame=<value optimized out>) at
/usr/src/sys/amd64/amd64/trap.c:620
#7 0xffffffff80845122 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231
#8 0xffffffff806d6668 in unp_gc (arg=0x10, pending=32) at
/usr/src/sys/kern/uipc_usrreq.c:2152
#9 0xffffffff8068f465 in taskqueue_run_locked (queue=0xfffff80012294600) at
/usr/src/sys/kern/subr_taskqueue.c:371
#10 0xffffffff80690258 in taskqueue_thread_loop (arg=<value optimized out>) at
/usr/src/sys/kern/subr_taskqueue.c:642
#11 0xffffffff80605a1a in fork_exit (callout=0xffffffff80690190
<taskqueue_thread_loop>, arg=0xffffffff80ee17c0, frame=0xfffffe01dd5d8c00) at
/usr/src/sys/kern/kern_fork.c:977
#12 0xffffffff8084565e in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:605
(kgdb) fr 8
#8 0xffffffff806d6668 in unp_gc (arg=0x10, pending=32) at
/usr/src/sys/kern/uipc_usrreq.c:2152
2152 fp = fdep[i]->fde_file;
(kgdb) list
2147 struct unpcb *unp;
2148 struct file *fp;
2149 int i;
2150
2151 for (i = 0; i < fdcount; i++) {
2152 fp = fdep[i]->fde_file;
2153 if ((unp = fptounp(fp)) == NULL)
2154 continue;
2155 if (unp->unp_gcflag & UNPGC_REF)
2156 continue;
(kgdb) disassemble
...
0xffffffff806d6660 <unp_gc+672>: mov 0x10(%rdx,%rax,8),%rcx
0xffffffff806d6665 <unp_gc+677>: mov (%rcx),%rcx
0xffffffff806d6668 <unp_gc+680>: cmpw $0x2,0x20(%rcx)
0xffffffff806d666d <unp_gc+685>: jne 0xffffffff806d66b0 <unp_gc+752>
0xffffffff806d666f <unp_gc+687>: mov (%rcx),%rcx
0xffffffff806d6672 <unp_gc+690>: test %rcx,%rcx
0xffffffff806d6675 <unp_gc+693>: je 0xffffffff806d66b0 <unp_gc+752>
0xffffffff806d6677 <unp_gc+695>: mov 0x20(%rcx),%rbx
0xffffffff806d667b <unp_gc+699>: cmp %r14,0x8(%rbx)
0xffffffff806d667f <unp_gc+703>: jne 0xffffffff806d66b0 <unp_gc+752>
0xffffffff806d6681 <unp_gc+705>: mov 0x10(%rcx),%r9
0xffffffff806d6685 <unp_gc+709>: test %r9,%r9
0xffffffff806d6688 <unp_gc+712>: je 0xffffffff806d66b0 <unp_gc+752>
0xffffffff806d668a <unp_gc+714>: movzwl 0x6a(%r9),%r10d
0xffffffff806d668f <unp_gc+719>: test $0x1,%r10b
0xffffffff806d6693 <unp_gc+723>: jne 0xffffffff806d66b0 <unp_gc+752>
0xffffffff806d6695 <unp_gc+725>: and $0xfffc,%r10d
0xffffffff806d669c <unp_gc+732>: or $0x1,%r10d
0xffffffff806d66a0 <unp_gc+736>: mov %r10w,0x6a(%r9)
0xffffffff806d66a5 <unp_gc+741>: incl 0xffffffff80e45604
0xffffffff806d66ac <unp_gc+748>: nopl 0x0(%rax)
0xffffffff806d66b0 <unp_gc+752>: inc %rax
0xffffffff806d66b3 <unp_gc+755>: cmp %r15d,%eax
0xffffffff806d66b6 <unp_gc+758>: jl 0xffffffff806d6660 <unp_gc+672>
...
(kgdb) i reg
rax 0x1 1
rbx 0xfffff800358713c0 -8795194977344
rcx 0x100000001 4294967297
rdx 0xfffff8006d327420 -8794260999136
rsi 0x20 32
rdi 0x10 16
rbp 0xfffffe01dd5d8b20 0xfffffe01dd5d8b20
rsp 0xfffffe01dd5d8aa0 0xfffffe01dd5d8aa0
r8 0xfffff8006d327400 -8794260999168
r9 0xffffffff809c07de -2137258018
r10 0xfffff80012294630 -8795788327376
r11 0xfffff8006d327400 -8794260999168
r12 0xfffff801e7420000 -8787918192640
r13 0x1fffffff8 8589934584
r14 0xffffffff80c535a8 -2134559320
r15 0x2 2
rip 0xffffffff806d6668 0xffffffff806d6668 <unp_gc+680>
eflags 0x10297 66199
....
(kgdb) p (struct filedescent**)(0xfffff8006d327420 + 0x10)
$8 = (struct filedescent **) 0xfffff8006d327430
(kgdb) p $8[0]
$9 = (struct filedescent *) 0xfffff800499a9d00
(kgdb) p $8[1]
$10 = (struct filedescent *) 0xfffff800499a9d30
(kgdb) p *$9
$11 = {fde_file = 0xfffff8016ccf7cf0, fde_caps = {fc_rights = {cr_rights = {0,
0}}, fc_ioctls = 0x1, fc_nioctls = 0, fc_fcntls = 0}, fde_flags = 0 '\0'}
(kgdb) p *$10
$12 = {fde_file = 0x100000001, fde_caps = {fc_rights = {cr_rights = {0, 0}},
fc_ioctls = 0x0, fc_nioctls = 0, fc_fcntls = 0}, fde_flags = 0 '\0'}
(kgdb) p $11.fde_file
$13 = (struct file *) 0xfffff8016ccf7cf0
(kgdb) p *$11.fde_file
$14 = {f_data = 0xfffff8002c001000, f_ops = 0xfffff801d391b588, f_cred =
0x17f0b, f_vnode = 0xffffffff809440d1, f_type = 0, f_vnread_flags = 625, f_flag
= 0, f_count = 0, f_seqcount = 0, f_nextoff = 1, f_vnun = {
fvn_cdevpriv = 0xffffffff809440dd, fvn_advice = 0xffffffff809440dd},
f_offset = 40960000, f_label = 0x0}
(kgdb) p *$14.f_ops
$15 = {fo_read = 0xffffffff8098daa8 <g_part_null_methods+216>, fo_write =
0xffffffff80bfab00 <zfs_vnodeops>, fo_truncate = 0xfffff8016ccf7cf0, fo_ioctl =
0xfffff8001aeb1990, fo_poll = 0, fo_kqfilter = 0xfffff801d391bb30,
fo_stat = 0, fo_close = 0, fo_chmod = 0, fo_chown = 0, fo_sendfile = 0,
fo_seek = 0xfffff801d391b5d8, fo_flags = 0}
(kgdb) p *$14.f_vnode
$16 = {v_tag = 0x6f6c5f7a3e2d707a <Address 0x6f6c5f7a3e2d707a out of bounds>,
v_op = 0x3e2d707a26006b63, v_data = 0x746e657261705f7a, ...}
So, it looks like elements of fdep[] point to some trashed data. Or the arrays
itself does not hold good values. I am not familiar with the code, but it
seems that unp_accessable() is invoked as a callback from unp_scan() which
passes data from control a message packet reinterpreted as an array of struct
filedescent pointers.
This is r271950 11.0-CURRENT.
I'd appreciate any suggestions.
It's hard to extract data because of all the inlining but if anyone would like
to see any additional data, then please let me know.
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5432E1C4.6090209>