On Sun, Jun 13, 2010 at 10:59:45PM -0700, Chuck Silvers wrote: > hi folks, > > ok, more progress. linux32 is working now and I fixed a few other bugs > along the way. > > the updated diff is in > ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/linux/diff.linux-nptl-take2.36
- mips pcb_tls. Can you use curlwp->l_private instead and add a cpu_lwp_setprivate() ala i386 to handle this? As it would be the same mechanism that we'd use for native TLS. There is a __HAVE flag for this in machine/types.h as far as I remember, see sys_lwp.c. I created patches for a bunch of other architectures to do this, mjf@ is sitting on them I think. - In x86 sys_machdep.c, I'd feel better if wrmsr() and set of pcb_gs etc were bracketed with kpreempt_disable()/kpreempt_enable(). Likewise memcpy() to pcb_gsd and friends in Linux compat code. - For the Linux compat setting of %gs/%fs, I'd rather this was done via a function call into native x86 code because in the past we've ended up with stragglers in this code, where someone working on compat does the wrong thing or where someone working on x86 fails to update the compat code. Not a strong opinion just a preference. - FYI I think I disabled Linux ptrace() because I was concerned about potential security issues and bitrot in the code. Dunno if that's still the case. - Re: the Linux +ucas_int() hack, preemption implies MULTIPROCESSOR so the kpreempt toggles aren't needed.. Maybe worthwhile as a sort of documentation though. We may context switch during the copyout so I don't see how this can be atomic. If copyin() is somehow wacky I guess we could switch there too. Any reason not to say "implement user space CAS or your port loses Linux emulation"? - The dup code for fork1() code makes me uncomfortable. Maybe it's worthwhile changing our native code so that LIDs are always allocated from the PID table or something along those lines? Tend to think these should be globally unique with the system and not just within a process. Could also be of potential help with things like inter-process pthread objects in shared memory. - When resetting l_lid, for safety we should hold p_lock (allthough during early fork we'd probably get away with it due to the process being SIDL). If we take an approach like the above then we wouldn't need to reset l_lid at all. > there is one odd thing that I haven't been able to figure out: > I don't think we should need to reload %gs in INTRFASTEXIT on amd64 > since swapgs will put back the user's gs.base value. > but if I take out the reload of %gs and run the 32-bit pthread tests, > within a few minutes the system will either reset or lock up. > anyone have any idea why this would be? I'd appreciate it if > someone could look over the asm code changes in general. No clear idea about the %gs issue, sorry.
