Panic in -current when using i386_set_ioperm()
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,) 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
Re: Panic in -current when using i386_set_ioperm()
On Sun, 21 Jul 2002, Mark Peek wrote: 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 There is a problem with set/get ioperm and threads (any variety) Ioperms should be a per-process thing, but the ioperm is stored as part of the information which turned out to be thread_specific. I.e the ioperm map is stored as part of the extended PCB as the extension of the TSS. The TSS holds information that on my reading appears to be largly thread-specific. (though some items might be interpreted as process specific) (hense the mess). The ioperm information is defined by Intel to be an extension to the context information that is in the ext-PCB, which is currently thread specific in -current.C Thus, when we change it, we need to sto pall threads, change the ioperm information or all of them and restart them, as the each have their own.. A least that is the way I remember it wothout going and looking at the 1/ sources 2/ intel docs. :-/ the iomap is in the extended pcb as ext_iomap. The extended pcb includes several things that should probably be per thread, including a TSS. I'm not sure, but there is maybe a possibility that all the TSSs in a process could share the pages used for the iomap. thus it would look like multiple TSSs but if you updated one iomap you updated the iomap for all of them. I dunnoit's a mess.. ideas anyone.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
