amd64/176835: Fatal trap 12: page fault while in kernel mode

[Martin Bishop]

>Number:         176835
>Category:       amd64
>Synopsis:       Fatal trap 12: page fault while in kernel mode
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-amd64
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Mar 11 06:50:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator:     Martin Bishop
>Release:        9.1
>Organization:
>Environment:
FreeBSD host.domain 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 09:23:10 UTC 2012     root at farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
Periodic panic, though it looks like it's happening in the same place. Stealing some advice from another bug report, there's some gdb output at the bottom..

panic #1
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0xffffffffd398481f
fault code              = supervisor write data, page not present
instruction pointer     = 0x20:0xffffffff808eb0b3
stack pointer           = 0x28:0xffffff80913d4970
frame pointer           = 0x28:0xffffff80913d4980
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         = 91049 (maildrop)
trap number             = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0xffffffff809208a6 at kdb_backtrace+0x66
#1 0xffffffff808ea8be at panic+0x1ce
#2 0xffffffff80bd8240 at trap_fatal+0x290
#3 0xffffffff80bd857d at trap_pfault+0x1ed
#4 0xffffffff80bd8b9e at trap+0x3ce
#5 0xffffffff80bc315f at calltrap+0x8
#6 0xffffffff808efb14 at tdsendsignal+0x454
#7 0xffffffff808f0b6d at killpg1+0x3bd
#8 0xffffffff808f0de4 at sys_kill+0x1e4
#9 0xffffffff80bd7ae6 at amd64_syscall+0x546

panic #2

Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0xffffffffd398481f
fault code              = supervisor write data, page not present
instruction pointer     = 0x20:0xffffffff808eb0b3
stack pointer           = 0x28:0xffffff8091109970
frame pointer           = 0x28:0xffffff8091109980
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         = 57769 (maildrop)
trap number             = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0xffffffff809208a6 at kdb_backtrace+0x66
#1 0xffffffff808ea8be at panic+0x1ce
#2 0xffffffff80bd8240 at trap_fatal+0x290
#3 0xffffffff80bd857d at trap_pfault+0x1ed
#4 0xffffffff80bd8b9e at trap+0x3ce
#5 0xffffffff80bc315f at calltrap+0x8
#6 0xffffffff808efb14 at tdsendsignal+0x454
#7 0xffffffff808f0b6d at killpg1+0x3bd
#8 0xffffffff808f0de4 at sys_kill+0x1e4
#9 0xffffffff80bd7ae6 at amd64_syscall+0x546

% gdb /boot/kernel/kernel
<snip>
(gdb) l *tdsendsignal+0x454
0xffffffff808efb14 is in tdsendsignal (/usr/src/sys/kern/kern_sig.c:2046).
warning: Source file is more recent than executable.

2041             * IEEE Std 1003.1-2001: return success when killing a zombie.
2042             */
2043            if (p->p_state == PRS_ZOMBIE) {
2044                    if (ksi && (ksi->ksi_flags & KSI_INS))
2045                            ksiginfo_tryfree(ksi);
2046                    return (ret);
2047            }
2048
2049            ps = p->p_sigacts;
2050            KNOTE_LOCKED(&p->p_klist, NOTE_SIGNAL | sig);
(gdb) 

I can grab a core if need be, but am hoping that given the consistency of the backtrace the problem will be obvious to the maintainers of the relevant portions of code :)
>How-To-Repeat:
I haven't been triggering it, but given the current process is consistently the same:

- run 9.1 release
- use maildrop to filter mail
- wait for crash

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted: