fusefs broken on 8-stable?
Gleb Kurtsou
gleb.kurtsou at gmail.com
Thu Dec 29 22:14:00 UTC 2011
On (29/12/2011 13:10), David P Discher wrote:
> Johannes - Were you able to get a resolution for this ?
>
> I've been able to replicate this panic in fiov_adjust(), but being called from vnlru, looks like its doing VOP_RECLAIM_APV().
>
> I'm willing to dive deeper and debug this, however would appreciate some guidance form the community. I'm having issues wrapping my head around macro FUSE_DIMALLOC(), which I think is using some sort of anonymous function call to get to fiov_adjust(). I've been battling this for a week or two now, so I have symbols in fuse module, so I have a bit more info.
There is alternative fuse port at https://github.com/glk/fuse-freebsd-ports
Could you try it and let us know if it works.
>
> ========================================
>
> (kgdb) up
> #11 0xffffffff81147412 in fdisp_make_pid (fdip=0xffffff9bce6399f0, mp=Variable "mp" is not available.
> )
> at fuse_msg.c:788
> 788 FUSE_DIMALLOC(&fdip->tick->tk_ms_fiov, fdip->finh,
> (kgdb) l
> 783 if (fdip->tick)
> 784 fticket_refresh(fdip->tick);
> 785 else
> 786 fdip->tick = fuse_ticket_fetch(data);
> 787
> 788 FUSE_DIMALLOC(&fdip->tick->tk_ms_fiov, fdip->finh,
> 789 fdip->indata, fdip->iosize);
> 790 fuse_setup_ihead(fdip->finh, fdip->tick, nid, op, fdip->iosize, pid, cred);
> 791 }
> 792
>
> (kgdb) p fdip
> $4 = (struct fuse_dispatcher *) 0xffffff9bce6399f0
> (kgdb) p *(struct fuse_dispatcher *)fdip
> $5 = {tick = 0x0, finh = 0x0, indata = 0xffffff9bce639a30, iosize = 8,
> nodeid = 0, answ_stat = 1356898584, answ = 0xffffff0350e0a138}
> (kgdb) p *(struct fuse_dispatcher *)fdip->tick
> Cannot access memory at address 0x0
>
> ==========================================
>
> (kgdb) up
> #9 0xffffffff807bd7b8 in calltrap ()
> at /usr/src/sys/amd64/amd64/exception.S:228
> 228 call trap
> Current language: auto; currently asm
> (kgdb) up
> #10 0xffffffff81146b17 in fiov_adjust (fiov=0x30, size=48) at fuse_msg.c:96
> 96 {
> Current language: auto; currently c
> (kgdb) l
> 91 free(fiov->base, M_FUSEMSG);
> 92 }
> 93
> 94 void
> 95 fiov_adjust(struct fuse_iov *fiov, size_t size)
> 96 {
> 97 if (fiov->allocated_size < size ||
> 98 (fuse_iov_permanent_bufsize >= 0 &&
> 99 fiov->allocated_size - size > fuse_iov_permanent_bufsize &&
> 100 --fiov->credit < 0)) {
>
>
> (kgdb) p fiov
> $1 = (struct fuse_iov *) 0x30
> (kgdb) p (struct fuse_iov *)fiov
> $2 = (struct fuse_iov *) 0x30
> (kgdb) p *(struct fuse_iov *)fiov
> Cannot access memory at address 0x30
> (kgdb) p size
> $3 = 48
>
> ==========================================
>
> (kgdb) bt
> #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:263
> #1 0xffffffff801f6c9c in db_fncall (dummy1=Variable "dummy1" is not available.
> )
> at /usr/src/sys/ddb/db_command.c:548
> #2 0xffffffff801f6fd1 in db_command (last_cmdp=0xffffffff80b67a40, cmd_table=Variable "cmd_table" is not available.
> )
> at /usr/src/sys/ddb/db_command.c:445
> #3 0xffffffff801f7220 in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:498
> #4 0xffffffff801f9269 in db_trap (type=Variable "type" is not available.
> ) at /usr/src/sys/ddb/db_main.c:229
> #5 0xffffffff80575ff1 in kdb_trap (type=12, code=0, tf=0xffffff9bce6398a0)
> at /usr/src/sys/kern/subr_kdb.c:548
> #6 0xffffffff807d4bad in trap_fatal (frame=0xffffff9bce6398a0, eva=Variable "eva" is not available.
> )
> at /usr/src/sys/amd64/amd64/trap.c:820
> #7 0xffffffff807d4eea in trap_pfault (frame=0xffffff9bce6398a0, usermode=0)
> at /usr/src/sys/amd64/amd64/trap.c:741
> #8 0xffffffff807d52ff in trap (frame=0xffffff9bce6398a0)
> at /usr/src/sys/amd64/amd64/trap.c:478
> #9 0xffffffff807bd7b8 in calltrap ()
> at /usr/src/sys/amd64/amd64/exception.S:228
> #10 0xffffffff81146b17 in fiov_adjust (fiov=0x30, size=48) at fuse_msg.c:96
> #11 0xffffffff81147412 in fdisp_make_pid (fdip=0xffffff9bce6399f0, mp=Variable "mp" is not available.
> )
> at fuse_msg.c:788
> #12 0xffffffff8114a6d4 in fuse_send_forget (mp=Variable "mp" is not available.
> ) at fuse_vnops.c:378
> #13 0xffffffff8114a7d6 in fuse_recyc_backend (vp=0xffffff0350e0a000,
> td=0xffffff0029533000) at fuse_vnops.c:539
> #14 0xffffffff808272fa in VOP_RECLAIM_APV (vop=0xffffffff811504e0,
> a=0xffffff9bce639a90) at vnode_if.c:1926
> #15 0xffffffff805ccf95 in vgonel (vp=0xffffff0350e0a000) at vnode_if.h:830
> #16 0xffffffff805cf9c4 in vnlru_free (count=28)
> at /usr/src/sys/kern/vfs_subr.c:975
> #17 0xffffffff805d030f in vnlru_proc () at /usr/src/sys/kern/vfs_subr.c:834
> #18 0xffffffff805211bd in fork_exit (callout=0xffffffff805cfec0 <vnlru_proc>,
> arg=0x0, frame=0xffffff9bce639c50) at /usr/src/sys/kern/kern_fork.c:876
> #19 0xffffffff807bdcfe in fork_trampoline ()
> at /usr/src/sys/amd64/amd64/exception.S:602
>
> ==========================================
>
>
>
> Fatal trap 12: page fault while in kernel mode^M
> cpuid = 7; apic id = 15^M
> fault virtual address = 0x40^M
> fault code = supervisor read data, page not present^M
> instruction pointer = 0x20:0xffffffff81146b17^M
> stack pointer = 0x28:0xffffff9bce639950^M
> frame pointer = 0x28:0xffffff9bce639980^M
> code segment = base 0x0, limit 0xfffff, type 0x1b^M
> = DPL 0, pres 1, long 1, def32 0, gran 1^M
> processor eflags = interrupt enabled, resume, IOPL = 0^M
> current process = 18 (vnlru)^M
> [thread pid 18 tid 100138 ]
> Stopped at fiov_adjust+0x17: movq 0x10(%rdi),%rax
> db> [-- MARK -- Thu Dec 29 01:15:00 2011]
> bt
> Tracing pid 18 tid 100138 td 0xffffff0029533000
> fiov_adjust() at fiov_adjust+0x17
> fdisp_make_pid() at fdisp_make_pid+0xd2
> fuse_send_forget() at fuse_send_forget+0x44
> fuse_recyc_backend() at fuse_recyc_backend+0xc6
> VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0x4a
> vgonel() at vgonel+0xf5
> vnlru_free() at vnlru_free+0x294
> vnlru_proc() at vnlru_proc+0x44f
> fork_exit() at fork_exit+0x11d
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffff9bce639d00, rbp = 0 ---
> db> call doadump
>
>
>
> ---
> David P. Discher
> dpd at bitgravity.com * AIM: bgDavidDPD
> BITGRAVITY * http://www.bitgravity.com
>
> On Jun 3, 2011, at 6:49 PM, Johannes Totz wrote:
>
> > On 13/05/2011 13:56, Johannes Totz wrote:
> >> Heya!
> >>
> >> Using encfs (built on top of fuse) gives me panics in combination with
> >> rsync. Dump didn't succeed. The info below is transcribbled from a
> >> photograph. This is repeatable.
> >> Without dump this is probably not very helpful....
> >>
> >>
> >> # uname -a
> >> FreeBSD XXX 8.2-STABLE FreeBSD 8.2-STABLE #1: Thu Mar 10 23:30:08 GMT
> >> 2011 root at XXX:/usr/obj/usr/src/sys/GENERIC amd64
> >
> > Managed to get a dump:
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 1; apic id = 01
> > fault virtual address = 0x40
> > fault code = supervisor read data, page not present
> > instruction pointer = 0x20:0xffffffff81f2ba3c
> > stack pointer = 0x28:0xffffff813aa2f570
> > frame pointer = 0x28:0xffffff813aa2f5a0
> > code segment = base 0x0, limit 0xfffff, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags = interrupt enabled, resume, IOPL = 0
> > current process = 1560 (rsync)
> > trap number = 12
> > panic: page fault
> > cpuid = 1
> > KDB: stack backtrace:
> > #0 0xffffffff805cc226 at kdb_backtrace+0x5c
> > #1 0xffffffff8059d000 at panic+0x1b4
> > #2 0xffffffff80875a75 at trap_fatal+0x394
> > #3 0xffffffff80875ce5 at trap_pfault+0x252
> > #4 0xffffffff808761b5 at trap+0x3f4
> > #5 0xffffffff8085f384 at calltrap+0x8
> > #6 0xffffffff81f2c170 at fdisp_make+0xe4
> > #7 0xffffffff81f3033d at fuse_lookup+0x1dc
> > #8 0xffffffff808caac8 at VOP_LOOKUP_APV+0x4c
> > #9 0xffffffff8061b0db at lookup+0x61e
> > #10 0xffffffff8061bf1f at namei+0x592
> > #11 0xffffffff80629df4 at kern_statat_vnhook+0x87
> > #12 0xffffffff80629f98 at kern_statat+0x15
> > #13 0xffffffff80629fb6 at kern_lstat+0x1c
> > #14 0xffffffff8062a03d at lstat+0x25
> > #15 0xffffffff805d7cf4 at syscallenter+0x2d9
> > #16 0xffffffff80875d45 at syscall+0x38
> > #17 0xffffffff8085f662 at Xfast_syscall+0xe2
> >
> >
> > #0 doadump () at pcpu.h:224
> > #1 0xffffffff8059cd12 in boot (howto=260) at
> > /usr/src/sys/kern/kern_shutdown.c:419
> > #2 0xffffffff8059d03b in panic (fmt=Variable "fmt" is not available.)
> > at /usr/src/sys/kern/kern_shutdown.c:592
> > #3 0xffffffff80875a75 in trap_fatal (frame=0xffffff813aa2f4c0, eva=64)
> > at /usr/src/sys/amd64/amd64/trap.c:809
> > #4 0xffffffff80875ce5 in trap_pfault (frame=0xffffff813aa2f4c0,
> > usermode=0) at /usr/src/sys/amd64/amd64/trap.c:725
> > #5 0xffffffff808761b5 in trap (frame=0xffffff813aa2f4c0) at
> > /usr/src/sys/amd64/amd64/trap.c:475
> > #6 0xffffffff8085f384 in calltrap () at
> > /usr/src/sys/amd64/amd64/exception.S:228
> > #7 0xffffffff81f2ba3c in fiov_adjust () from /usr/local/modules/fuse.ko
> > #8 0xffffffff81f2c170 in fdisp_make () from /usr/local/modules/fuse.ko
> > #9 0xffffffff81f3033d in fuse_lookup () from /usr/local/modules/fuse.ko
> > #10 0xffffffff808caac8 in VOP_LOOKUP_APV (vop=0x0, a=0x30) at vnode_if.c:123
> > #11 0xffffffff8061b0db in lookup (ndp=0x618) at vnode_if.h:54
> > #12 0xffffffff8061bf1f in namei (ndp=0xffffff813aa2f8e0) at
> > /usr/src/sys/kern/vfs_lookup.c:269
> > #13 0xffffffff80629df4 in kern_statat_vnhook (td=0xffffff00039f2460,
> > flag=Variable "flag" is not available.) at
> > /usr/src/sys/kern/vfs_syscalls.c:2346
> > #14 0xffffffff80629f98 in kern_statat (td=Variable "td" is not
> > available.) at /usr/src/sys/kern/vfs_syscalls.c:2327
> > #15 0xffffffff80629fb6 in kern_lstat (td=Variable "td" is not
> > available.) at /usr/src/sys/kern/vfs_syscalls.c:2400
> > #16 0xffffffff8062a03d in lstat (td=Variable "td" is not available.) at
> > /usr/src/sys/kern/vfs_syscalls.c:2390
> > #17 0xffffffff805d7cf4 in syscallenter (td=0xffffff00039f2460,
> > sa=0xffffff813aa2fbc0) at /usr/src/sys/kern/subr_trap.c:315
> > #18 0xffffffff80875d45 in syscall (frame=0xffffff813aa2fc50) at
> > /usr/src/sys/amd64/amd64/trap.c:914
> > #19 0xffffffff8085f662 in Xfast_syscall () at
> > /usr/src/sys/amd64/amd64/exception.S:381
> > #20 0x000000080097a5dc in ?? ()
> >
> > At #10 a=0x30 looks dodgy and fault address is 0x40, but I have no idea
> > what that means...
> >
> > _______________________________________________
> > freebsd-fs at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> > To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
More information about the freebsd-fs
mailing list