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.
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
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
I dunno....it's a mess.. ideas anyone..
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message