Bug #2083

panic: vm_fault: fault on stack guard, addr: 0xffffffe01dbea000

Added by herrgard about 3 years ago. Updated about 3 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Hi. I get this on x86_64 master. I don't know how to reproduce, but it happened on my box just now three times within one hour.

DragonFly zoidberg.luxh.dyndns.info 2.11-DEVELOPMENT DragonFly v2.11.0.281.g34c13-DEVELOPMENT #13: Sat May 28 03:25:11 CEST 2011 :/usr/obj/usr/src/sys/X86_64_GENERIC x86_64

panic: vm_fault: fault on stack guard, addr: 0xffffffe01dbea000
cpuid = 0
Trace beginning at frame 0xffffffe01dbed778
panic() at panic+0x1ed
panic() at panic+0x1ed
vm_fault() at vm_fault+0x1ed
trap_pfault() at trap_pfault+0x103
trap() at trap+0x43e
calltrap() at calltrap+0x8
--- trap 000000000000000c, rip = ffffffff80712e86, rsp = ffffffe01dbedab0, rbp = ffffffe01dbedb30 ---
ovbcopy() at ovbcopy+0x16
rl_rxeof() at rl_rxeof+0x10b
rl_intr() at rl_intr+0x7e
lwkt_serialize_handler_call() at lwkt_serialize_handler_call+0x80
ithread_handler() at ithread_handler+0x1ac
Debugger("panic")

(kgdb) bt
#0 _get_mycpu (di=<value optimized out>) at ./machine/thread.h:69
#1 md_dumpsys (di=<value optimized out>) at /usr/src/sys/platform/pc64/x86_64/dump_machdep.c:263
#2 0xffffffff8047ba45 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:927
#3 0xffffffff8047c0ab in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:389
#4 0xffffffff8047c354 in panic (fmt=0xffffffff80764604 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:833
#5 0xffffffff80296eb5 in db_panic (addr=<value optimized out>, have_addr=0, count=0, modif=0x0) at /usr/src/sys/ddb/db_command.c:448
#6 0xffffffff8029757f in db_command () at /usr/src/sys/ddb/db_command.c:344
#7 db_command_loop () at /usr/src/sys/ddb/db_command.c:470
#8 0xffffffff8029a411 in db_trap (type=<value optimized out>, code=<value optimized out>) at /usr/src/sys/ddb/db_trap.c:71
#9 0xffffffff80713ff8 in kdb_trap (type=<value optimized out>, code=<value optimized out>, regs=<value optimized out>) at /usr/src/sys/platform/pc64/x86_64/db_interface.c:176
#10 0xffffffff80719b06 in trap (frame=0xffffffe01dbed6a8) at /usr/src/sys/platform/pc64/x86_64/trap.c:701
#11 0xffffffff807125ae in calltrap () at /usr/src/sys/platform/pc64/x86_64/exception.S:187
#12 0xffffffff80713e8f in breakpoint (msg=<value optimized out>) at ./cpu/cpufunc.h:73
#13 Debugger (msg=<value optimized out>) at /usr/src/sys/platform/pc64/x86_64/db_interface.c:361
#14 0xffffffff8047c334 in panic (fmt=0xffffffff807f1c88 "vm_fault: fault on stack guard, addr: %p") at /usr/src/sys/kern/kern_shutdown.c:824
#15 0xffffffff8067f8b3 in vm_fault (map=0xffffffff80c933a0, vaddr=18446743936769630208, fault_type=<value optimized out>, fault_flags=<value optimized out>)
at /usr/src/sys/vm/vm_fault.c:334
#16 0xffffffff8071950f in trap_pfault (frame=0xffffffe01dbed9f8, usermode=<value optimized out>) at /usr/src/sys/platform/pc64/x86_64/trap.c:864
#17 0xffffffff80719a52 in trap (frame=0xffffffe01dbed9f8) at /usr/src/sys/platform/pc64/x86_64/trap.c:591
#18 0xffffffff807125ae in calltrap () at /usr/src/sys/platform/pc64/x86_64/exception.S:187
#19 0xffffffff80712e86 in ovbcopy () at /usr/src/sys/platform/pc64/x86_64/support.s:113
#20 0xffffffff804c1128 in m_devget (buf=0xffffffe01dbe9fda "", len=1073, offset=<value optimized out>, ifp=<value optimized out>, copy=<value optimized out>)
at /usr/src/sys/kern/uipc_mbuf.c:1858
#21 0xffffffff805e4e8f in rl_rxeof (sc=0xffffffe0191b39f0) at /usr/src/sys/dev/netif/rl/if_rl.c:1056
#22 0xffffffff805e5303 in rl_intr (arg=<value optimized out>) at /usr/src/sys/dev/netif/rl/if_rl.c:1233
#23 0xffffffff8048c51a in lwkt_serialize_handler_call (s=0xffffffe0191b3d90, func=0xffffffff805e5285 <rl_intr>, arg=0xffffffe0191b39f0, frame=0x0)
at /usr/src/sys/kern/lwkt_serialize.c:229
#24 0xffffffff80453cc4 in ithread_handler (arg=<value optimized out>) at /usr/src/sys/kern/kern_intr.c:824
#25 0xffffffff80486bcd in lwkt_deschedule_self (td=0xffffffe042322020) at /usr/src/sys/kern/lwkt_thread.c:283
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

-Max

History

#1 Updated by dillon about 3 years ago

:Hi. I get this on x86_64 master. I don't know how to reproduce, but it happened on my box just now three times within one hour.
:

It looks like rl_rxeof() is making an illegal call to m_devget(). The
comment in the code says it all:

/*
* Fool m_devget() into thinking we want to copy
* the whole buffer so we don't end up fragmenting
* the data.
*/
m = m_devget(rxbufpos - RL_ETHER_ALIGN,
total_len + RL_ETHER_ALIGN, 0, ifp, NULL);

The 'fool' part is that it's calling m_devget() with a buffer range
that goes beyond the buffer's EOF, and then using m_copyback() to
re-copy the real data.

The panic will depend heavily on what memory is beyond the
sc->rl_cdata.rl_rx_buf buffer... if the buffer was allocated next
to a stack guard, you'd get that error.

-Matt

#2 Updated by sepherosa about 3 years ago

On Sat, May 28, 2011 at 10:40 PM, Max Herrgard <> wrote:
> Hi. I get this on x86_64 master. I don't know how to reproduce, but it happened on my box just now three times within one hour.

It looks like a bug left over from ice age. Please test following patch:
http://leaf.dragonflybsd.org/~sephe/if_rl.diff

Best Regards,
sephe

#3 Updated by herrgard about 3 years ago

On 29 maj 2011, at 13.12, Sepherosa Ziehau wrote:
> It looks like a bug left over from ice age. Please test following patch:
> http://leaf.dragonflybsd.org/~sephe/if_rl.diff

I've run this for three days now with the box doing the same thing as before and it didn't panic. So I'd say it's fixed.

Good the stack guards are there :)

-luxh

#4 Updated by herrgard about 3 years ago

b4877f07bf57a0db94c2e2e0547ab834bfdc43ca

Also available in: Atom PDF