Date: Wed, 09 Dec 2009 20:59:23 +0000 From: Thomas Hurst <tom@hur.st> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/141328: Xen: gstat exit causes kernel panic from unmanaged virtual address Message-ID: <E1NITd5-000FhL-Pa@voi.aagh.net> Resent-Message-ID: <200912092140.nB9Le1Ec048034@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 141328
>Category: kern
>Synopsis: Xen: gstat exit causes kernel panic from unmanaged virtual address
>Confidential: no
>Severity: critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Dec 09 21:40:01 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator: Thomas Hurst
>Release: FreeBSD 8.0-STABLE
>Organization:
>Environment:
System: FreeBSD mzu.aagh.net 8.0-STABLE FreeBSD 8.0-STABLE #0: Wed Dec 9 19:59:29 GMT 2009 root@mzu.aagh.net:/usr/obj/usr/src/sys/MZU_XEN i386
Dom0 is 64bit Debian Lenny (stable) running Xen 3.2.1. VM is paravirtualized.
>Description:
Under Xen paravirtualisation, running and then exiting gstat results in
the following error and kernel panic:
va=0x2823f000 is unmanaged :-( pte=0x80000007062d0025
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4
fault code = supervisor read, page not present
instruction pointer = 0x21:0xc0329faa
stack pointer = 0x29:0xe4b9bb10
frame pointer = 0x29:0xe4b9bb24
code segment = base 0x0, limit 0xf9800, type 0x1b
= DPL 1, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 726 (gstat)
[thread pid 726 tid 100051 ]
Stopped at pmap_mapdev+0x25a: movl 0x4(%ebx),%edx
Tracing pid 726 tid 100051 td 0xc3839d80
pmap_mapdev(c08be6cc,80,62d0025,80000007,0,...) at pmap_mapdev+0x25a
pmap_remove_all(e4b9bb90,7,0,2823d000,0,...) at pmap_remove_all+0x51e
pmap_remove(c3438288,2823f000,28242000,9,0,...) at pmap_remove+0x2a3
vm_map_delete(c34381d8,1000,bf800000,1,c34381d8,...) at vm_map_delete+0x189
vm_map_remove(c34381d8,1000,bf800000,c35b9540,0,...) at vm_map_remove+0x51
vmspace_exit(c3839d80,c381faa0,3,e4b9bc74,0,...) at vmspace_exit+0xbe
exit1(c3839d80,0,e4b9bd3c,c0334455,c3839d80,...) at exit1+0x663
sys_exit(c3839d80,e4b9bd08,4,c,c,...) at sys_exit+0x1d
syscall(e4b9bd48) at syscall+0x325
Xint0x80_syscall() at Xint0x80_syscall+0x22
--- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x2818d0af, esp = 0xbf7fe9bc, ebp = 0xbf7fe9c8 ---
I guess this is related to it mmapping /dev/devstat via geom_stats_*().
procstat -v shows the address is indeed mapped:
PID START END PRT RES PRES REF SHD FL TP PATH
822 0x8048000 0x804c000 r-x 4 0 1 0 CN vn /usr/sbin/gstat
822 0x804c000 0x8100000 rw- 1 0 1 0 -- df
822 0x2804c000 0x2807c000 r-x 43 0 50 24 CN vn /libexec/ld-elf.so.1
822 0x2807c000 0x2807e000 rw- 2 0 1 0 C- vn /libexec/ld-elf.so.1
822 0x2807e000 0x28091000 rw- 13 0 1 0 -- df
822 0x28091000 0x28095000 r-x 4 5 2 1 CN vn /lib/libdevstat.so.7
822 0x28095000 0x28096000 rw- 1 0 1 0 C- vn /lib/libdevstat.so.7
822 0x28096000 0x2809e000 r-x 8 8 2 1 CN vn /lib/libkvm.so.5
822 0x2809e000 0x2809f000 rw- 1 0 1 0 C- vn /lib/libkvm.so.5
822 0x2809f000 0x280a3000 r-x 4 4 2 1 CN vn /lib/libgeom.so.5
822 0x280a3000 0x280a4000 rw- 1 0 1 0 C- vn /lib/libgeom.so.5
822 0x280a4000 0x280c1000 r-x 29 30 2 1 CN vn /lib/libbsdxml.so.4
822 0x280c1000 0x280c3000 rw- 2 0 1 0 C- vn /lib/libbsdxml.so.4
822 0x280c3000 0x280c5000 r-x 2 2 2 1 CN vn /lib/libsbuf.so.5
822 0x280c5000 0x280c6000 rw- 1 0 1 0 C- vn /lib/libsbuf.so.5
822 0x280c6000 0x280da000 r-x 20 0 6 3 CN vn /lib/libedit.so.7
822 0x280da000 0x280db000 rw- 1 0 1 0 C- vn /lib/libedit.so.7
822 0x280db000 0x28118000 r-x 60 0 10 5 CN vn /lib/libncurses.so.8
822 0x28118000 0x2811b000 rw- 3 0 1 0 C- vn /lib/libncurses.so.8
822 0x2811b000 0x28217000 r-x 98 0 50 24 CN vn /lib/libc.so.7
822 0x28217000 0x2821d000 rw- 6 0 1 0 C- vn /lib/libc.so.7
822 0x2821d000 0x28233000 rw- 7 0 1 0 -- df
822 0x28233000 0x2823c000 rw- 2 0 2 0 -- df
822 0x2823c000 0x2823d000 r-- 0 0 3 0 -- dv
822 0x2823d000 0x2823f000 r-- 0 0 3 0 -- dv
==> 822 0x2823f000 0x28242000 r-- 3 0 3 0 -- dv
822 0x28300000 0x28400000 rw- 49 0 2 0 -- df
822 0xbf7e0000 0xbf800000 rwx 5 0 1 0 -- df
Adding a call to geom_stats_close() at the end of gstat.c results in
kernel livelock; it responds to ping but nothing else.
This problem seems to be well known, including being mentioned on
the FreeBSD wiki, but I couldn't find an associated PR.
>How-To-Repeat:
Run gstat under a PV Xen instance, quit.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1NITd5-000FhL-Pa>