There is a reproducible panic in -current after using
i386_set_ioperm(). The extended pcb is attempted to be freed in
cpu_thread_exit() using kmem_free(). Via private mail, Alan Cox
explained it to me as such:
"The problem runs deeper than Giant not being held: cpu_thread_exit()
really can't call kmem_free(). At the point of the call, a spin lock
is held. Acquiring the kernel_map lock can cause you to sleep. Thus,
the code could sleep with a spin lock held."
The program and the panic trace is below. I figured I would post this
to -current to get some more people thinking about the right fix.
Mark
-------
#include <stdio.h>
#include <stdlib.h>
#include <machine/sysarch.h>
int
main()
{
int bt_ctrl = 0xe4;
if (i386_set_ioperm(bt_ctrl, 3, 1) != 0) {
perror("i386_set_ioperm");
exit(1);
}
}
panic: mutex Giant not owned at /usr/src/sys/vm/vm_map.c:364
Debugger("panic")
Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c03e1c1c) at Debugger+0x45
panic(c03e0de8,c03e0f52,c03ff0f8,16c,c0832000) at panic+0x7c
_mtx_assert(c043f000,1,c03ff0f8,16c) at _mtx_assert+0xa8
_vm_map_lock(c0832000,c03ff0f8,842) at _vm_map_lock+0x23
vm_map_remove(c0832000,ed506000,ed509000,e8ce7c84,c038d055) at
vm_map_remove+0x1f
kmem_free(c0832000,ed506000,3000,c62bbb40,e8ce7ca0) at kmem_free+0x25
cpu_thread_exit(c62bbb40) at cpu_thread_exit+0x35
thread_exit(c62bbb40,c6a18000,e8ce7cd4,c024d4af,c043f000) at thread_exit+0x8a
exit1(c62bbb40,1038a800,c043f000,0,c03debce) at exit1+0xb67
sys_exit(c62bbb40,e8ce7d14,1,16,296) at sys_exit+0x27
syscall(bfbf002f,bfbf002f,bfbf002f,0,ffffffff) at syscall+0x23c
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280a1d13, esp =
0xbfbffb7c, ebp = 0xbfbffba8 ---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
