Re: HEAD'S UP: fusefs sysctls going away

From: Marek Zarychta <zarychtam_at_plan-b.pwste.edu.pl>
Date: Sat, 6 Apr 2019 19:50:20 +0200
W dniu 06.04.2019 o 17:28, Alan Somers pisze:

> On Sat, Apr 6, 2019 at 8:52 AM Marek Zarychta <zarychtam_at_plan-b.pwste.edu.pl>
> wrote:
>
>>>> After recent changes in fusefs code I am getting such panics regularly
>>>> on amd64:
>>>>
>>>>
>>>> Fatal trap 12: page fault while in kernel mode
>>>> cpuid = 3; apic id = 03
>>>> fault virtual address    = 0x248
>>>> fault code        = supervisor read data  , page not present
>>>> instruction pointer    = 0x20:0xffffffff82d6250c
>>>> stack pointer            = 0x28:0xfffffe005dc2c630
>>>> frame pointer            = 0x28:0xfffffe005dc2c7b0
>>>> 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        = 2016 (mount_fusefs)
>>>> trap number        = 12
>>>> panic: page fault
>>>> cpuid = 3
>>>> time = 1554528396
>>>> KDB: stack backtrace:
>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>>> 0xfffffe005dc2c2e0
>>>> vpanic() at vpanic+0x19d/frame 0xfffffe005dc2c330
>>>> panic() at panic+0x43/frame 0xfffffe005dc2c390
>>>> trap_fatal() at trap_fatal+0x394/frame 0xfffffe005dc2c3f0
>>>> trap_pfault() at trap_pfault+0x49/frame 0xfffffe005dc2c450
>>>> trap() at trap+0x29f/frame 0xfffffe005dc2c560
>>>> calltrap() at calltrap+0x8/frame 0xfffffe005dc2c560
>>>> --- trap 0xc, rip = 0xffffffff82d6250c, rsp = 0xfffffe005dc2c630, rbp =
>>>> 0xfffffe005dc2c7b0 ---
>>>> fuse_vfsop_mount() at fuse_vfsop_mount+0x5dc/frame 0xfffffe005dc2c7b0
>>>> vfs_domount() at vfs_domount+0xace/frame 0xfffffe005dc2c9e0
>>>> vfs_donmount() at vfs_donmount+0x934/frame 0xfffffe005dc2ca80
>>>> sys_nmount() at sys_nmount+0x69/frame 0xfffffe005dc2cac0
>>>> amd64_syscall() at amd64_syscall+0x36e/frame 0xfffffe005dc2cbf0
>>>> fast_syscall_common() at fast_syscall_common+0x101/frame
>>>> 0xfffffe005dc2cbf0
>>>> --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8002d510a, rsp =
>>>> 0x7fffffffe128, rbp = 0x7fffffffe730 ---
>>>> KDB: enter: panic
>>>>
>>>> Last time I have checked it happened on FreeBSD 13.0-CURRENT #21
>>>> r345948: Fri Apr  5 17:12:53 CEST 2019.
>>>>
>>>> As a workaround loading fusefs.ko and fuse.ko modules can be disabled.
>>>>
>>>> --
>>>> Marek Zarychta
>>> Thanks for the bug report.  This is probably fixed by r345419 (which
>>> hasn't been merged to head yet).  If so, then it indicates that your fuse daemon
>>> is doing something wrong.  What fuse file system are you trying to use, and
>>> what command are you using to start it?
>>> -Alan
>> XFCE4 desktop environment seems to be the culprit of the whole anxiety.
>> It has installed fusefs-libs-2.9.9 as a dependency. I get these panics
>> during the XFCE session startup. Furthermore, I haven't any fusefs
>> packages installed beside mentioned fusefs-libs.
>>
>> --
>> Marek Zarychta
>
> Then the culprit is probably /usr/local/libexec/gvfsd-fuse.  But on my
> XFCE4 system, that command never runs.  I don't know why not.  Try this
> patch:
> https://reviews.freebsd.org/D19836
>
> -Alan

Thank you for the fast-tracked patch. It resolves the issue.

I have XFCE4  coexisting with Gnome and some extra,  non-native disk
partitions on this workstation, this is probably the cause that
/usr/local/libexec/gvfsd-fuse comes into play.

-- 
Marek Zarychta



Received on Sat Apr 06 2019 - 15:50:34 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC