Date: Sun, 21 Jul 2002 22:36:29 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Mark Peek <mp@FreeBSD.org> Cc: freebsd-current@freebsd.org, Alan Cox <alc@FreeBSD.org>, julian@freebsd.org Subject: Re: Panic in -current when using i386_set_ioperm() Message-ID: <Pine.BSF.4.21.0207212218080.2198-100000@InterJet.elischer.org> In-Reply-To: <p05111a0ab960f2187817@[10.1.1.73]>
next in thread | previous in thread | raw e-mail | index | archive | help
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 dunno....it's a mess.. ideas anyone.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0207212218080.2198-100000>