I mount a directory from a remote server via sshfs to my zpool partition. Next I open an encrypted container in the sshfs mounted directory with encfs. Finally, when I attempt to rsync data into the unencrypted encfs mounted container the system immediately throws a Page Fault and totally freezes up. Even the core dump fails to complete. This is all the information( from the terminal screen ) of the fault I have. **************************************************** Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20 :0x0 stack pointer = 0x28 :0xffffff80559cdad0 frame pointer = 0x28 :0xffffff80559cdb20 code segment = base rx0, limit 0xffffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1632 (rsync) trap number = 12 panic: page fault cupid = 1 KDB: stack backtrace: #0 0xffffffff808680fe at kdb_backtrace+0x5e #1 0xffffffff80832cb7 at panic+0x187 #2 0xffffffff80b18400 at trap_fatal+0x290 #3 0xffffffff80b18749 at trap_pfault+0x1f9 #4 0xffffffff80b18c0f at trap+0x3df #5 0xffffffff80b0313f at calltrap+0x8 #6 0xffffffff80b17cf0 at amd64_syscall+0x450 #7 0xffffffff80b03427 at Zfast_syscall+0xf7 ********************************************************** I have tried this on both a zpool and a zpool on top of geli containers and gotten the same page fault every time. I have previously done this same procedure on Ubuntu and Gentoo servers with no problems. How-To-Repeat: sshfs <user>@<remote Server>:/home/<user> /mnt/archive encfs -S /mnt/archive/.crypt /archive rsync -avzqrpogtu /stuff /archive
Responsible Changed From-To: freebsd-bugs->gnn fuse maintianer
Responsible Changed From-To: gnn->freebsd-bugs
Responsible Changed From-To: freebsd-bugs->fs Give to the Filesystem mailing list.
Responsible Changed From-To: fs->freebsd-fs Reassign from fs@freebsd.org to freebsd-fs@freebsd.org as that is where all the other filesystem bugs are kept.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
I can't reproduce on 13.0-CURRENT. I'm going to hazard a guess that this crash was fixed by the new in-kernel fusefs(5) driver which replaced the old sysutils/fusefs-kmod port.