Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
Julian Elischer wrote:
It's not that likely to roll, but...
static int complained = 6;
if (complained-- ) {
if (complained) {
complained--;
printf (process (PID %d) Use static LDT allocation.\n,
td-td_proc-p_pid);
printf (man i386_set_ldt for more information\n);
}
-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
Marcel Moolenaar wrote: But if we only use the dynamic allocation then it can only fail for a combination of 3rd party code. You meant to say static here, e.g. when there are two libraries linked into a single aplication, and both libraries want to get entry #6, right? In the dynamic case, this will Just Work(tm), because each one will end up getting a different value. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
Julian Elischer wrote:
+ if (ldt_warnings++ NUM_LDT_WARNINGS) {
Still broken on rollover; use:
+ if (ldt_warnings NUM_LDT_WARNINGS) {
+ ldt_warnings++;
-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote: looking at it further, it appears that NLDT is not really a 'reservation' as much as a description of how much space we may need to allocate initially. Correct, except it seems that there are some bugs from the kernel using the code and data selectors see another reply). I think that it wouldn't matter (for example) if you used one of the existing defined numbers as long as you are not running a program that used them.. i.e you could use as you are not a BSDI binary that needs it. Even changing the code and data selectors so that user code can't run should be just foot shooting. It seems to be allowed before rev.1.84. The LDT is a user resource and the kernel can do very little about applications and libraries mismanaging it. It can just help them manage it. Dynamic allocation seems to be a correct first step towards letting them manage it. Also it's interesting to note that '0' is defined.. this is intersting as a value of a segment register of '0' is not allowed from my memory. I guess that only applies to GDTEs. Correct. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote: On Fri, 1 Aug 2003, Julian Elischer wrote: I also noticed that if we disable the 'splat' mode, we'd break sysVR4 binary code as they do that.. (though it's #if 0'd out at the moment) not to mention linux (more important..) though I might add that that code could do with rewriting to get rid of a lot of stackgap stuff. Even changing the semantics of i386_set_ldt() to support dynamic allocation may break ABI compatibility with Linux (not to mention both API and ABI compatibility with OtherBSD). I wondered about this when the change was proposed, but only had a quick look at an old version of Linux for API compatibility. Linux seem to have a different API. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Sat, Aug 02, 2003 at 01:53:31AM -0700, Terry Lambert wrote: Marcel Moolenaar wrote: But if we only use the dynamic allocation then it can only fail for a combination of 3rd party code. You meant to say static here, e.g. when there are two libraries linked into a single aplication, and both libraries want to get entry #6, right? Yes. My wording was incomplete. In the dynamic case, this will Just Work(tm), because each one will end up getting a different value. Correct. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
Hi, after upgrading the Kernel I found that the glx-related programs of the NVidia graphics driver die in calls to sysarch. Here is a truss fragment of a 'glxinfo' run: sysarch(0x1,0xbfbffb14) ERR#22 'Invalid argument' SIGNAL 10 SIGNAL 10 Process stopped because of: 16 process exit, rval = 138 In the sysarch call the first argument indicats - according to machine/sysarch.h - a call of I386_SET_LDT. For 4.X it was necessary to enable USER_LDT in the kernel config. This option is no longer present in the kernel config (the NVidia driver worked without before my cvs update...). Best regards -Thorsten -- For every complex problem, there is a solution that is simple, neat, and wrong. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Thorsten Greiner wrote: Hi, after upgrading the Kernel I found that the glx-related programs of the NVidia graphics driver die in calls to sysarch. Here is a truss fragment of a 'glxinfo' run: sysarch(0x1,0xbfbffb14)ERR#22 'Invalid argument' SIGNAL 10 SIGNAL 10 Process stopped because of: 16 process exit, rval = 138 In the sysarch call the first argument indicats - according to machine/sysarch.h - a call of I386_SET_LDT. For 4.X it was necessary to enable USER_LDT in the kernel config. This option is no longer present in the kernel config (the NVidia driver worked without before my cvs update...). Hmmm, well I know we changed the semantics of the I386_SET_LDT call a bit but as far as I could see it was a backwards compatible change.. can you compile your sys_machdep.c with the option -DDEBUG? I noticed there is a debug printf that is enabled byu this and may show what request the NVIDIA people are making. Best regards -Thorsten -- For every complex problem, there is a solution that is simple, neat, and wrong. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
* Julian Elischer [EMAIL PROTECTED] [2003-08-01 23:44]: can you compile your sys_machdep.c with the option -DDEBUG? I noticed there is a debug printf that is enabled byu this and may show what request the NVIDIA people are making. This is what gets logged: Aug 1 23:42:43 tybalt kernel: i386_set_ldt: start=6 num=1 descs=0xbfbff724 I will test wether the problem still occurs with version 1.84 of sys_machdep.c and let you know. Regards -Thorsten -- Those who in quarrels interpose, must often wipe a bloody nose. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
* Thorsten Greiner [EMAIL PROTECTED] [2003-08-01 23:47]: I will test wether the problem still occurs with version 1.84 of sys_machdep.c and let you know. Yup, reverting to 1.84 unbreaks this for me. Looking at the changes made it appears to me that the check if (uap-start NLDT || uap-num = 0) return (EINVAL);i causes this, because NLDT is 6 and the NVidia stuff passes uap-start == 6 to this call. Regards -Thorsten -- Adding manpower to a late software project makes it later ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Thorsten Greiner wrote: * Thorsten Greiner [EMAIL PROTECTED] [2003-08-01 23:47]: I will test wether the problem still occurs with version 1.84 of sys_machdep.c and let you know. Yup, reverting to 1.84 unbreaks this for me. Looking at the changes made it appears to me that the check if (uap-start NLDT || uap-num = 0) return (EINVAL);i causes this, because NLDT is 6 and the NVidia stuff passes uap-start == 6 to this call. It can't use 6. FreeBSD reserves 0-16 for its own use. I think the bug was in the old code allowing this to happen... -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Daniel Eischen wrote: On Fri, 1 Aug 2003, Thorsten Greiner wrote: * Thorsten Greiner [EMAIL PROTECTED] [2003-08-01 23:47]: I will test wether the problem still occurs with version 1.84 of sys_machdep.c and let you know. Yup, reverting to 1.84 unbreaks this for me. Looking at the changes made it appears to me that the check if (uap-start NLDT || uap-num = 0) return (EINVAL);i causes this, because NLDT is 6 and the NVidia stuff passes uap-start == 6 to this call. It can't use 6. FreeBSD reserves 0-16 for its own use. I think the bug was in the old code allowing this to happen... Looking at segments.h. /* * Entries in the Local Descriptor Table (LDT) */ #define LSYS5CALLS_SEL 0 /* forced by intel BCS */ #define LSYS5SIGR_SEL 1 #define L43BSDCALLS_SEL 2 /* notyet */ #define LUCODE_SEL 3 #define LSOL26CALLS_SEL 4 /* Solaris = 2.6 system call gate */ #define LUDATA_SEL 5 /* separate stack, es,fs,gs sels ? */ /* #define LPOSIXCALLS_SEL 5*/ /* notyet */ #define LBSDICALLS_SEL 16 /* BSDI system call gate */ #define NLDT(LBSDICALLS_SEL + 1) it looks like NLDT should be save between from 6 to 15 (though I wish they'd chosen a different value) so we could add: if ((uap-start == LBSDICALLS_SEL) || (uap-start = LUDATA_SEL)) || (uap-num = 0)) ... What do you think? -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
* Daniel Eischen [EMAIL PROTECTED] [2003-08-02 00:06]: I think the bug was in the old code allowing this to happen... Well, than someone should tell that to NVidia. Their driver is closed source and comes without user servicable parts. Regards -Thorsten -- There are 10 kinds of people in the world, those who understand binary and those who don't. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On 2003-08-02 00:20 +0200, Thorsten Greiner wrote: * Daniel Eischen [EMAIL PROTECTED] [2003-08-02 00:06]: I think the bug was in the old code allowing this to happen... Well, than someone should tell that to NVidia. Their driver is closed source and comes without user servicable parts. Regards -Thorsten That's going to be a lot easier to get through if someone can confirm whether 0-16 are reserved, or whether (like julian says), 6-15 are actually safe and something else is being clobbered. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote: On Fri, 1 Aug 2003, Daniel Eischen wrote: On Fri, 1 Aug 2003, Thorsten Greiner wrote: * Thorsten Greiner [EMAIL PROTECTED] [2003-08-01 23:47]: I will test wether the problem still occurs with version 1.84 of sys_machdep.c and let you know. Yup, reverting to 1.84 unbreaks this for me. Looking at the changes made it appears to me that the check if (uap-start NLDT || uap-num = 0) return (EINVAL);i causes this, because NLDT is 6 and the NVidia stuff passes uap-start == 6 to this call. It can't use 6. FreeBSD reserves 0-16 for its own use. I think the bug was in the old code allowing this to happen... Looking at segments.h. /* * Entries in the Local Descriptor Table (LDT) */ #define LSYS5CALLS_SEL 0 /* forced by intel BCS */ #define LSYS5SIGR_SEL 1 #define L43BSDCALLS_SEL 2 /* notyet */ #define LUCODE_SEL 3 #define LSOL26CALLS_SEL 4 /* Solaris = 2.6 system call gate */ #define LUDATA_SEL 5 /* separate stack, es,fs,gs sels ? */ /* #define LPOSIXCALLS_SEL 5*/ /* notyet */ #define LBSDICALLS_SEL 16 /* BSDI system call gate */ #define NLDT(LBSDICALLS_SEL + 1) it looks like NLDT should be save between from 6 to 15 (though I wish they'd chosen a different value) so we could add: I might add that this si slightly bogus as you an't have aproces being a BSDI binary and a SOLARIS binary and a BCS binary all at the same time, and we don't set any values on most (any?) of these segments for FreeBSD binaries.. if ((uap-start == LBSDICALLS_SEL) || (uap-start = LUDATA_SEL)) || (uap-num = 0)) ... What do you think? -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote: On Fri, 1 Aug 2003, Daniel Eischen wrote: On Fri, 1 Aug 2003, Thorsten Greiner wrote: * Thorsten Greiner [EMAIL PROTECTED] [2003-08-01 23:47]: I will test wether the problem still occurs with version 1.84 of sys_machdep.c and let you know. Yup, reverting to 1.84 unbreaks this for me. Looking at the changes made it appears to me that the check if (uap-start NLDT || uap-num = 0) return (EINVAL);i causes this, because NLDT is 6 and the NVidia stuff passes uap-start == 6 to this call. It can't use 6. FreeBSD reserves 0-16 for its own use. I think the bug was in the old code allowing this to happen... Looking at segments.h. /* * Entries in the Local Descriptor Table (LDT) */ #define LSYS5CALLS_SEL 0 /* forced by intel BCS */ #define LSYS5SIGR_SEL 1 #define L43BSDCALLS_SEL 2 /* notyet */ #define LUCODE_SEL 3 #define LSOL26CALLS_SEL 4 /* Solaris = 2.6 system call gate */ #define LUDATA_SEL 5 /* separate stack, es,fs,gs sels ? */ /* #define LPOSIXCALLS_SEL 5*/ /* notyet */ #define LBSDICALLS_SEL 16 /* BSDI system call gate */ #define NLDT(LBSDICALLS_SEL + 1) it looks like NLDT should be save between from 6 to 15 (though I wish they'd chosen a different value) so we could add: if ((uap-start == LBSDICALLS_SEL) || (uap-start = LUDATA_SEL)) || (uap-num = 0)) ... What do you think? I think it could work, but do we want it to work? If we are really reserving the first 17 (16 really, since 0 is invalid), then what are we to do if we want to use another one? Do we add NVidia's LDTs to segments.h so that we, or anyone else, will not use them? We could make a new syscall and use the old one for compat behavior, or make it a compile time option... If they ever recompile, they really want to be using the new interface, so I think breaking it by default would be good. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Munish Chopra wrote: On 2003-08-02 00:20 +0200, Thorsten Greiner wrote: * Daniel Eischen [EMAIL PROTECTED] [2003-08-02 00:06]: I think the bug was in the old code allowing this to happen... Well, than someone should tell that to NVidia. Their driver is closed source and comes without user servicable parts. Regards -Thorsten That's going to be a lot easier to get through if someone can confirm whether 0-16 are reserved, or whether (like julian says), 6-15 are actually safe and something else is being clobbered. I think that they are safe.. looking at it further, it appears that NLDT is not really a 'reservation' as much as a description of how much space we may need to allocate initially. I think that it wouldn't matter (for example) if you used one of the existing defined numbers as long as you are not running a program that used them.. i.e you could use as you are not a BSDI binary that needs it. Given this.. it would appear that maybe the whole idea needs to be looked at again. Also it's interesting to note that '0' is defined.. this is intersting as a value of a segment register of '0' is not allowed from my memory. I guess that only applies to GDTEs. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Saturday 02 August 2003 06:24, Munish Chopra wrote: On 2003-08-02 00:20 +0200, Thorsten Greiner wrote: * Daniel Eischen [EMAIL PROTECTED] [2003-08-02 00:06]: I think the bug was in the old code allowing this to happen... Well, than someone should tell that to NVidia. Their driver is closed source and comes without user servicable parts. Regards -Thorsten That's going to be a lot easier to get through if someone can confirm whether 0-16 are reserved, or whether (like julian says), 6-15 are actually safe and something else is being clobbered. #define LSYS5CALLS_SEL 0 /* forced by intel BCS */ #define LSYS5SIGR_SEL 1 #define L43BSDCALLS_SEL 2 /* notyet */ #define LUCODE_SEL 3 #define LSOL26CALLS_SEL 4 /* Solaris = 2.6 system call gate */ #define LUDATA_SEL 5 /* separate stack, es,fs,gs sels ? */ /* #define LPOSIXCALLS_SEL 5*/ /* notyet */ #define LBSDICALLS_SEL 16 /* BSDI system call gate */ #define NLDT(LBSDICALLS_SEL + 1) 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. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Sat, 2 Aug 2003, David Xu wrote: On Saturday 02 August 2003 06:24, Munish Chopra wrote: On 2003-08-02 00:20 +0200, Thorsten Greiner wrote: * Daniel Eischen [EMAIL PROTECTED] [2003-08-02 00:06]: I think the bug was in the old code allowing this to happen... Well, than someone should tell that to NVidia. Their driver is closed source and comes without user servicable parts. Regards -Thorsten That's going to be a lot easier to get through if someone can confirm whether 0-16 are reserved, or whether (like julian says), 6-15 are actually safe and something else is being clobbered. #define LSYS5CALLS_SEL 0 /* forced by intel BCS */ #define LSYS5SIGR_SEL 1 #define L43BSDCALLS_SEL 2 /* notyet */ #define LUCODE_SEL 3 #define LSOL26CALLS_SEL 4 /* Solaris = 2.6 system call gate */ #define LUDATA_SEL 5 /* separate stack, es,fs,gs sels ? */ /* #define LPOSIXCALLS_SEL 5*/ /* notyet */ #define LBSDICALLS_SEL 16 /* BSDI system call gate */ #define NLDT(LBSDICALLS_SEL + 1) 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. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
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. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Sat, 2 Aug 2003, David Xu wrote: On Saturday 02 August 2003 06:24, Munish Chopra wrote: On 2003-08-02 00:20 +0200, Thorsten Greiner wrote: * Daniel Eischen [EMAIL PROTECTED] [2003-08-02 00:06]: I think the bug was in the old code allowing this to happen... Well, than someone should tell that to NVidia. Their driver is closed source and comes without user servicable parts. Regards -Thorsten That's going to be a lot easier to get through if someone can confirm whether 0-16 are reserved, or whether (like julian says), 6-15 are actually safe and something else is being clobbered. #define LSYS5CALLS_SEL 0 /* forced by intel BCS */ #define LSYS5SIGR_SEL 1 #define L43BSDCALLS_SEL 2 /* notyet */ #define LUCODE_SEL 3 #define LSOL26CALLS_SEL 4 /* Solaris = 2.6 system call gate */ #define LUDATA_SEL 5 /* separate stack, es,fs,gs sels ? */ /* #define LPOSIXCALLS_SEL 5*/ /* notyet */ #define LBSDICALLS_SEL 16 /* BSDI system call gate */ #define NLDT(LBSDICALLS_SEL + 1) 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. Of course, but there are pre-exisiting binaries that use a selector of 6. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Daniel Eischen wrote: 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. I think that for now we can allow anything over 6 because we are not a BSDI binary. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
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). I can see the need to keep the old behavoir for compatibility's sake. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote: On Fri, 1 Aug 2003, Daniel Eischen wrote: 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. I think that for now we can allow anything over 6 because we are not a BSDI binary. make that over 5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, 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). I can see the need to keep the old behavoir for compatibility's sake. How about we complain loudly on the console when it's done.. (for the first few times) (with info on how to do it right) -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote: On Fri, 1 Aug 2003, Daniel Eischen wrote: 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. I think that for now we can allow anything over 6 because we are not a BSDI binary. That's a quick fix, yes. But I still think we should put things in place to disallow this and favor the dynamic ldt creation. I can only see it rearing its ugly head at some point in the future when our thread libraries get more widespread use. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote: On Fri, 1 Aug 2003, Daniel Eischen wrote: 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). I can see the need to keep the old behavoir for compatibility's sake. How about we complain loudly on the console when it's done.. (for the first few times) (with info on how to do it right) And make a new interface, changing the prototype in the header file, so old uses of it fail to compile??? -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote:
I can see the need to keep the old behavoir for compatibility's
sake.
How about we complain loudly on the console when it's done..
(for the first few times)
(with info on how to do it right)
static int complained = 6;
if (complained-- ) {
printf (process (PID %d) Use static LDT allocation.\n,
td-td_proc-p_pid);
printf (man i386_set_ldt for more information\n);
}
and fix the man paget to indicate that static alloacation
is frowned upon.
We should however allow it to succeed if it doesn't collide
with LUDATA or LUCODE I think.
(if they are set)
julian
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
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 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Marcel Moolenaar wrote: 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. note that a 0 value turns out to be valid.. we had thougth it was invalid when we did the dynamic code ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Daniel Eischen wrote: On Fri, 1 Aug 2003, Julian Elischer wrote: How about we complain loudly on the console when it's done.. (for the first few times) (with info on how to do it right) And make a new interface, changing the prototype in the header file, so old uses of it fail to compile??? This could be a royal pain for someone in a hurry.. I think just the message would be enough to annoy them to fix it.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Marcel Moolenaar wrote: 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: 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). If your 3rd party code is a library, and other application code is built to be threaded (or use other libraries that are threaded) _and_ use this 3rd party library, then you have a problem. You don't know what ldt allocation is going to come first. If our dynamic allocations are made first and the 3rd party static allocations are made next, then you can have something whacky ensue. It may not even be the same all the time; it could depend on which button a user clicks first. OpenGL is the example that I was thinking about. 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. This is all good :-) -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Daniel Eischen wrote:
On Fri, 1 Aug 2003, Marcel Moolenaar wrote:
OpenGL is the example that I was thinking about.
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.
This is all good :-)
Here's my first patch..
I'd suggest this (along with man page change) to go in first
for a while before we break people's code.
cvs server: Diffing .
Index: sys_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/sys_machdep.c,v
retrieving revision 1.86
diff -u -r1.86 sys_machdep.c
--- sys_machdep.c 31 Jul 2003 08:20:24 - 1.86
+++ sys_machdep.c 1 Aug 2003 23:58:29 -
@@ -410,6 +410,9 @@
return(error);
}
+static int ldt_warnings;
+#define NUM_LDT_WARNINGS 10
+
static int
i386_set_ldt(td, args)
struct thread *td;
@@ -441,7 +444,7 @@
uap-start = NLDT;
uap-num = MAX_LD - NLDT;
}
- if (uap-start NLDT || uap-num = 0)
+ if (uap-start = LUDATA_SEL || uap-num = 0)
return (EINVAL);
mtx_lock_spin(sched_lock);
pldt = mdp-md_ldt;
@@ -460,10 +463,16 @@
}
if (!(uap-start == 0 uap-num == 1)) {
+ /* complain a for a while if using old methods */
+ if (ldt_warnings++ NUM_LDT_WARNINGS) {
+ printf(Warning: pid %d used static ldt
allocation.\n,
+ td-td_proc-p_pid);
+ printf(See the i386_set_ldt man page for more
info\n);
+ }
/* verify range of descriptors to modify */
largest_ld = uap-start + uap-num;
- if (uap-start NLDT || uap-start = MAX_LD ||
uap-num 0 ||
- largest_ld MAX_LD) {
+ if (uap-start = LUDATA_SEL || uap-start = MAX_LD ||
+ uap-num 0 || largest_ld MAX_LD) {
return (EINVAL);
}
}
@@ -562,7 +571,7 @@
again:
mtx_lock_spin(sched_lock);
dp = ((union descriptor *)(pldt-ldt_base))[NLDT];
- for (i = NLDT; i pldt-ldt_len; ++i) {
+ for (i = LUDATA_SEL + 1; i pldt-ldt_len; ++i) {
if (dp-sd.sd_type == SDT_SYSNULL)
break;
dp++;
(beware white space munging.. (copypaste))
I'd follow this with actual breakage oafer say 3 months.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote:
Here's my first patch..
I'd suggest this (along with man page change) to go in first
for a while before we break people's code.
cvs server: Diffing .
Index: sys_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/sys_machdep.c,v
retrieving revision 1.86
diff -u -r1.86 sys_machdep.c
--- sys_machdep.c 31 Jul 2003 08:20:24 - 1.86
+++ sys_machdep.c 1 Aug 2003 23:58:29 -
@@ -410,6 +410,9 @@
return(error);
}
+static int ldt_warnings;
+#define NUM_LDT_WARNINGS 10
+
static int
i386_set_ldt(td, args)
struct thread *td;
@@ -441,7 +444,7 @@
uap-start = NLDT;
uap-num = MAX_LD - NLDT;
}
- if (uap-start NLDT || uap-num = 0)
+ if (uap-start = LUDATA_SEL || uap-num = 0)
return (EINVAL);
mtx_lock_spin(sched_lock);
pldt = mdp-md_ldt;
@@ -460,10 +463,16 @@
}
if (!(uap-start == 0 uap-num == 1)) {
+ /* complain a for a while if using old methods */
+ if (ldt_warnings++ NUM_LDT_WARNINGS) {
+ printf(Warning: pid %d used static ldt
allocation.\n,
+ td-td_proc-p_pid);
+ printf(See the i386_set_ldt man page for more
info\n);
+ }
/* verify range of descriptors to modify */
largest_ld = uap-start + uap-num;
- if (uap-start NLDT || uap-start = MAX_LD ||
uap-num 0 ||
- largest_ld MAX_LD) {
+ if (uap-start = LUDATA_SEL || uap-start = MAX_LD ||
+ uap-num 0 || largest_ld MAX_LD) {
return (EINVAL);
}
}
@@ -562,7 +571,7 @@
again:
mtx_lock_spin(sched_lock);
dp = ((union descriptor *)(pldt-ldt_base))[NLDT];
- for (i = NLDT; i pldt-ldt_len; ++i) {
+ for (i = LUDATA_SEL + 1; i pldt-ldt_len; ++i) {
Looks OK, but if we are doing a dynamic allocation, it might be
better to start at NLDT just to avoid the known problem of someone
using 6... Just a thought.
--
Dan Eischen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Daniel Eischen wrote:
On Fri, 1 Aug 2003, Julian Elischer wrote:
Here's my first patch..
I'd suggest this (along with man page change) to go in first
for a while before we break people's code.
cvs server: Diffing .
Index: sys_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/sys_machdep.c,v
retrieving revision 1.86
diff -u -r1.86 sys_machdep.c
--- sys_machdep.c 31 Jul 2003 08:20:24 - 1.86
+++ sys_machdep.c 1 Aug 2003 23:58:29 -
@@ -410,6 +410,9 @@
return(error);
}
+static int ldt_warnings;
+#define NUM_LDT_WARNINGS 10
+
static int
i386_set_ldt(td, args)
struct thread *td;
@@ -441,7 +444,7 @@
uap-start = NLDT;
uap-num = MAX_LD - NLDT;
}
- if (uap-start NLDT || uap-num = 0)
+ if (uap-start = LUDATA_SEL || uap-num = 0)
return (EINVAL);
mtx_lock_spin(sched_lock);
pldt = mdp-md_ldt;
@@ -460,10 +463,16 @@
}
if (!(uap-start == 0 uap-num == 1)) {
+ /* complain a for a while if using old methods */
+ if (ldt_warnings++ NUM_LDT_WARNINGS) {
+ printf(Warning: pid %d used static ldt
allocation.\n,
+ td-td_proc-p_pid);
+ printf(See the i386_set_ldt man page for more
info\n);
+ }
/* verify range of descriptors to modify */
largest_ld = uap-start + uap-num;
- if (uap-start NLDT || uap-start = MAX_LD ||
uap-num 0 ||
- largest_ld MAX_LD) {
+ if (uap-start = LUDATA_SEL || uap-start = MAX_LD ||
+ uap-num 0 || largest_ld MAX_LD) {
return (EINVAL);
}
}
@@ -562,7 +571,7 @@
again:
mtx_lock_spin(sched_lock);
dp = ((union descriptor *)(pldt-ldt_base))[NLDT];
- for (i = NLDT; i pldt-ldt_len; ++i) {
+ for (i = LUDATA_SEL + 1; i pldt-ldt_len; ++i) {
Looks OK, but if we are doing a dynamic allocation, it might be
better to start at NLDT just to avoid the known problem of someone
using 6... Just a thought.
sure.. (though we don't know how many they use we just saw the first
one fail).
of course they only link with linux threads.
when they link with us they's use our %gs..
I also noticed that if we disable the 'splat' mode, we'd break sysVR4
binary code as they do that.. (though it's #if 0'd out at the moment)
--
Dan Eischen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote: Looks OK, but if we are doing a dynamic allocation, it might be better to start at NLDT just to avoid the known problem of someone using 6... Just a thought. sure.. (though we don't know how many they use we just saw the first one fail). of course they only link with linux threads. when they link with us they's use our %gs.. I also noticed that if we disable the 'splat' mode, we'd break sysVR4 binary code as they do that.. (though it's #if 0'd out at the moment) not to mention linux (more important..) though I might add that that code could do with rewriting to get rid of a lot of stackgap stuff. (i386/linux/linux_machdep.c around line 630) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
