From owner-freebsd-bugs@FreeBSD.ORG Fri Nov 14 04:49:52 2014 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07E5BB52 for ; Fri, 14 Nov 2014 04:49:52 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD73DB5B for ; Fri, 14 Nov 2014 04:49:51 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sAE4npn7017045 for ; Fri, 14 Nov 2014 04:49:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 195000] New: [patch] rsync -a to fuse fs may cause kernel panic Date: Fri, 14 Nov 2014 04:49:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: henry.hu.sh@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 04:49:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195000 Bug ID: 195000 Summary: [patch] rsync -a to fuse fs may cause kernel panic Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: henry.hu.sh@gmail.com Created attachment 149389 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=149389&action=edit temporary fix for the crash I've hit a crash in the fuse module when doing a rsync to an ntfs volume mounted with ntfs-3g. To reproduce, just use "rsync -a" to sync a dir to a NTFS volume mounted with ntfs-3g, and put a socket in that dir. The crash is the same as ones reported before, in https://lists.freebsd.org/pipermail/freebsd-current/2013-October/045993.html and there are other similar reports: http://www.bsdforen.de/threads/probleme-mit-rsync-und-sshfs.29323/ I'm posting their backtrace here: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x64 fault code = supervisor read, page not present instruction pointer = 0x20:0xcae6adb6 stack pointer = 0x28:0xf0ac29a0 frame pointer = 0x28:0xf0ac2a0c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 14116 (conftest) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: #0 0xc0aed942 at kdb_backtrace+0x52 #1 0xc0ab37e1 at panic+0x121 #2 0xc0f8df09 at trap_fatal+0x339 #3 0xc0f8e23d at trap_pfault+0x31d #4 0xc0f8d819 at trap+0x519 #5 0xc0f776ec at calltrap+0x6 #6 0xc0fb2864 at VOP_CREATE_APV+0x94 #7 0xc0b355ab at uipc_bindat+0x36b #8 0xc0b33307 at uipc_bind+0x27 #9 0xc0b2c277 at kern_bindat+0x147 #10 0xc0b2c064 at sys_bind+0x74 #11 0xc0f8e939 at syscall+0x479 #12 0xc0f77781 at Xint0x80_syscall+0x21 Uptime: 1d23h57m34s Physical memory: 2027 MB <...> (kgdb) #0 doadump (textdump=-961984384) at pcpu.h:233 #1 0xc0ab3459 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xc0ab381f in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xc0f8df09 in trap_fatal (frame=, eva=100) at /usr/src/sys/i386/i386/trap.c:1047 #4 0xc0f8e23d in trap_pfault (frame=0x0, usermode=, eva=0) at /usr/src/sys/i386/i386/trap.c:859 #5 0xc0f8d819 in trap (frame=0xf0ac2960) at /usr/src/sys/i386/i386/trap.c:556 #6 0xc0f776ec in calltrap () at /usr/src/sys/i386/i386/exception.s:170 #7 0xcae6adb6 in fuse_vnop_create (ap=0x0) at /usr/src/sys/modules/fuse/../../fs/fuse/fuse_vnops.c:368 #8 0xc0fb2864 in VOP_CREATE_APV (vop=, a=0xf0ac2b88) at vnode_if.c:265 #9 0xc0b355ab in uipc_bindat (so=0xf0ac2b20, nam=, td=) at vnode_if.h:109 #10 0xc0b33307 in uipc_bind (so=0xc80ab9f0, nam=0xc8580e80, td=0xce271620) at /usr/src/sys/kern/uipc_usrreq.c:573 #11 0xc0b2c277 in kern_bindat (td=0xce271620, dirfd=, fd=, sa=0xce271620) at /usr/src/sys/kern/uipc_syscalls.c:283 #12 0xc0b2c064 in sys_bind (td=0x0, uap=) at /usr/src/sys/kern/uipc_syscalls.c:297 #13 0xc0f8e939 in syscall (frame=) at subr_syscall.c:134 #14 0xc0f77781 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:270 #15 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) This may be related to bug 167362, but in that case, RIP is 0, which means that it should be a different problem. Bug 182739 is similar to bug 167362. After digging it a bit, I found that the problem is in fuse_vnop_create(). Check https://github.com/freebsd/freebsd/blame/master/sys/fs/fuse/fuse_vnops.c#L337. At line 337, it checks if vap->va_type is VREG, and if it is not, it goes to label bringup. Then, feo is assigned with fdip->answ and used. But fdip which points to fdi is initialized after the goto. As a result, when vap->va_type != VREG, fdi is not initialized and feo is invalid. I made a patch and it works for me. In my case, the problematic file is a socket. But I think that fuse filesystems may support file types other than VREG, so maybe we should remove that check completely? In fuse4x for mac, https://github.com/fuse4x/kext/blob/master/fuse_vnops.c#L375, the logic is similar, but the flow is different. -- You are receiving this mail because: You are the assignee for the bug.