tech-pkg archive
[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index][
Old Index]
Re: updating COMPAT_LINUX for linux 2.6.x support (take 2)
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.
Home |
Main Index |
Thread Index |
Old Index