I submit that the current implementation of useracc() is utterly
useless -- and *broken*.

All it currently does is check the permissions on the page within the
vm_map.  The only cases where we even call it are when we expect to
copy something in or out of that region of user space[1]; effectively
all useracc() does is give us early detection of errors.  `What's the
point?'

Back in the day, useracc() was used to check permissions on the space
used to hold a signal context, so that the kernel could directly frob
the area in user space.  This provided a small but nice little speedup
in signal handling, by avoiding having to copy the data structure out
and then back into the kernel.  (This is effectively equivalent to
what Linux's VERIFY_AREA() does, except that they use it in place of
having copyin()/copyout() as well.)

[1] Some ports actually still use it for accessing signal contexts.
However, *these ports are potentially broken*, because useracc() does
not currently handle copy-on-write at all.  (This would, for example,
fail on the genuine i386, which does not honor the write-protect bit
in supervisor mode -- were it not that the i386 port was modified to
use copyin()/copyout() for signal contexts a long time ago.)  In
addition, because it's a potentially expensive function (having to
search through the vm_map), it negates any speedup we might have
gained.

So, I'd like to remedy this.  Either we should fix useracc() or we
should remove it.  To fix it, I suggest:

* Make it a machine-dependent function.  Have it check the permissions
  in the page table and iff that fails call (u)vm_fault(), to handle
  copy-on-write, etc.  (For reading, we could possibly just have it
  try to read the page!  Very fast...)

* Eliminate the extraneous uses of it just to detect errors early.
  This is kind of pointless.

* On ports with shared address spaces, switch back to using useracc()
  and accessing the signal context directly.


Any comments from the cashew gallery?