fusefs broken on 8-stable?

[Johannes Totz]

On 13/05/2011 14:19, Gleb Kurtsou 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....
> 
> As far as I know there is memory corruption. But this particular case
> looks like VFS bug in fuse.
> 
> I'd appreciate if you give native FreeBSD kernel level cryptographic
> filesystem PEFS a try:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/156002 -- port
> http://wiki.freebsd.org/PEFS
> https://github.com/glk/pefs

Looks interesting...

I was relying on encfs's reverse-mode though: given a plaintext
directory, it provides an encrypted view on-the-fly which I was
rsync'ing to other file servers.

>> # 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
>>
>>
>>
>> First panic (top bits scrolled off screen):
>>
>> trap number = 12
>> panic: page fault
>> cpuid = 0
>> KDB: stack backtrace
>> #0 ... kbd_backtrace+0x5c
>> #1 ... panic+0x1b4
>> #2 ... trap_fatal+0x394
>> #3 ... trap_pfault+0x252
>> #4 ... trap+0x3f4
>> #5 ... calltrap+0x8
>> #6 ... fdisp_make+0xe4
>> #7 ... fuse_lookup+0x1dc
>> #8 ... VOP_LOOKUP_APV+0x4c
>> #9 ... at lookup+0x61e
>> #10 ... at namei+0x592
>> #11 ... at vn_open_cred+0x339
>> #12 ... at vn_open+0x1c
>> #13 ... at kern_openat+0x152
>> #14 ... at kern_open+0x19
>> #15 ... at open+0x18
>> #16 ... at syscallenter+0x2d9
>> #17 ... at syscall+0x38
>>
>>
>>
>> Second panic:
>>
>>
>> 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 = 17 (vnlru)
>> trap number = 12
>> panic: page fault
>> cpuid = 0
>> KDB: stack backtrace
>> #0 ... at kdb_backtrace+0x5c
>> #1 ... at panic+0x1b4
>> #2 ... at trap_fatal+0x394
>> #3 ... at trap_pfault0x252
>> #4 ... at trap+0x3f4
>> #5 ... at calltrap+0x8
>> #6 ... at fdisp_make_pid+0xc7
>> #7 ... at fuse_send_forget+0x44
>> #8 ... at fuse_recyc_backend+0xb2
>> #9 ... at VOP_RECLAIM_APV+0x49
>> #10 ... at vgonel+0x1b7
>> #11 ... at vnlru_proc+0x591
>> #12 ... at fork_exit+0x121
>> #13 ... at fork_trampoline+0xe
>>
>>
>>
>> Any idea what could be going on?
>>
>>
>> Johannes