Re: updating COMPAT_LINUX for linux 2.6.x support (take 2)

[Andrew Doran <ad%NetBSD.org@localhost>]

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.