Date: Mon, 08 Nov 2010 12:35:55 +0100 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-current@freebsd.org Cc: freebsd-fs@freebsd.org Subject: Re: another fuse panic Message-ID: <ib8nas$9de$1@dough.gmane.org> In-Reply-To: <4CD7C8FC.900@icyb.net.ua> References: <4CD7C8FC.900@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/08/10 10:55, Andriy Gapon wrote:
>
> JFYI.
> Fatal trap 12: page fault while in kernel mode
Can you find any set of circumstances which make this repeatable?
This panic apparently goes like this:
1) used by devfs_open():
47 static struct cdevsw fuse_cdevsw = {
48 .d_open = fusedev_open,
2) in fusedev_open():
119 fdata = fdata_alloc(dev, td->td_ucred);
3) in fdata_alloc():
297 data->daemoncred = crhold(cred);
in other words, td->td_ucred from td passed to fusedev_open (presumably
when the device is opened from the userland) appears to be NULL.
I don't know if there is any normal set of circumstances under which
this is expected.
> cpuid = 1; apic id = 01
> fault virtual address = 0x0
> fault code = supervisor write data, page not present
> instruction pointer = 0x20:0xffffffff80372a64
> stack pointer = 0x28:0xffffff81265486f0
> frame pointer = 0x28:0xffffff8126548700
> 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 = 4080 (initial thread)
> trap number = 12
> panic: page fault
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0xffffffff801b9b8a = db_trace_self_wrapper+0x2a
> kdb_backtrace() at 0xffffffff803b36ba = kdb_backtrace+0x3a
> panic() at 0xffffffff8037c8b2 = panic+0x1d2
> trap_fatal() at 0xffffffff8055b35d = trap_fatal+0x39d
> trap_pfault() at 0xffffffff8055b638 = trap_pfault+0x2b8
> trap() at 0xffffffff8055bd33 = trap+0x603
> calltrap() at 0xffffffff80545f78 = calltrap+0x8
> --- trap 0xc, rip = 0xffffffff80372a64, rsp = 0xffffff81265486f0, rbp =
> 0xffffff8126548700 ---
> crhold() at 0xffffffff80372a64 = crhold+0x4
> fdata_alloc() at 0xffffffff80e17a9f = fdata_alloc+0xcf
> fusedev_open() at 0xffffffff80e1896e = fusedev_open+0xae
> devfs_open() at 0xffffffff802e8fa7 = devfs_open+0x117
> VOP_OPEN_APV() at 0xffffffff805bb0c4 = VOP_OPEN_APV+0x74
> vn_open_cred() at 0xffffffff804222bd = vn_open_cred+0x4ad
> vn_open() at 0xffffffff804223dc = vn_open+0x1c
> kern_openat() at 0xffffffff80420bad = kern_openat+0x15d
> kern_open() at 0xffffffff80420f29 = kern_open+0x19
> open() at 0xffffffff80420f48 = open+0x18
> syscallenter() at 0xffffffff803c0f9e = syscallenter+0x3be
> syscall() at 0xffffffff8055b6b1 = syscall+0x41
> Xfast_syscall() at 0xffffffff80546252 = Xfast_syscall+0xe2
>
> NULL pointer is passed as an argument to crhold.
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ib8nas$9de$1>