Date: Fri, 1 Aug 2003 16:37:58 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: deischen@freebsd.org Cc: current@freebsd.org Subject: Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...) Message-ID: <20030801233758.GA7023@dhcp01.pn.xcllnt.net> In-Reply-To: <Pine.GSO.4.10.10308011911520.321-100000@pcnet5.pcnet.com> References: <20030801230157.GA6323@dhcp01.pn.xcllnt.net> <Pine.GSO.4.10.10308011911520.321-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 01, 2003 at 07:18:11PM -0400, Daniel Eischen wrote: > On Fri, 1 Aug 2003, Marcel Moolenaar wrote: > > > On Fri, Aug 01, 2003 at 06:51:33PM -0400, Daniel Eischen wrote: > > > > > > LUCODE_SEL is used by kernel to load _ucodesel to user %cs > > > > LUDATA_SEL is used by kernel to load _udatasel to user %ds, %es, %fs, %gs. > > > > I didn't check other ABIs, but setting to a fixed location of LDT in userland > > > > is also a bad idea, I think it will conflict with thread library soon, > > > > it is better to use dynamic allocating facility newly added in i386_set_ldt. > > > > > > Perhaps we need to rethink the interface and disallow > > > specification of any ldt; only allow dynamic. We would > > > need a different method of setting an array of them, though. > > > > Why not allow setting a specific entry when it's currently unused > > and not reserved by us? > > We can simply fail if the process is trying to set a LDT entry that's > > currently being used or is reserved by us. The only case that causes > > problems is when an existing LDT entry is overwritten by another > > consumer. > > That's what I was worried about. Once an application or > library is written to use specific LDTs, you never know > how it will be affected by the use of threading libraries > (or other libraries using threads). But if we only use the dynamic allocation then it can only fail for a combination of 3rd party code. It should always work when there's just one 3rd party piece of code involved. This makes it work for anything we should care about. The moment a process is constructed with various 3rd party pieces compatibility is out of our hands anyway (compatibility between the various 3rd party pieces that is). Having a way to disallow using the static allocation should be easy if we use compiler magic to test that the LDT entry is constant and 0. If it is, all is ok (assuming that I'm not mistaken that we use a 0 entry to indicate dynamic allocation -- I haven't actually paid that close attention to it). If the LDT entry is non-constant, it can still be 0 of course but I expect that to be a weird border case. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030801233758.GA7023>