From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 16:38:00 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BFBF37B401; Fri, 1 Aug 2003 16:38:00 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A21D43F85; Fri, 1 Aug 2003 16:37:59 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h71NbwwO005170; Fri, 1 Aug 2003 16:37:58 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h71NbwA5007948; Fri, 1 Aug 2003 16:37:58 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h71NbwDY007943; Fri, 1 Aug 2003 16:37:58 -0700 (PDT) (envelope-from marcel) Date: Fri, 1 Aug 2003 16:37:58 -0700 From: Marcel Moolenaar To: deischen@freebsd.org Message-ID: <20030801233758.GA7023@dhcp01.pn.xcllnt.net> References: <20030801230157.GA6323@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: David Xu cc: current@freebsd.org Subject: Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2003 23:38:00 -0000 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