Skip site navigation (1)Skip section navigation (2)
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>