Re: RFC: New userspace fetch/store API

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, Feb 24, 2019 at 08:47:12AM -0800, Jason Thorpe wrote:
 > 
 > > On Feb 24, 2019, at 8:42 AM, David Holland <dholland-tech%netbsd.org@localhost> wrote:
 > > Given that the alignment check _is_ free on some architectures, and
 > > that dealing with alignment in machine-independent C is problematic,
 > > that doesn't seem like the right way?
 > 
 > If we?re concerned about portability of the things using this API,
 > then we simply specify the alignment to be sizeof(type).  That
 > check is straight-forward in MI C.

No, even if you know what the alignment's supposed to be, you can't
legally check it. Or maybe you can, but it's in any event tangled in a
bunch of language-lawyering.

Also, these days you can expect the compiler to simply remove such
checks on the grounds that all pointers to types with required
alignment are expected to be already aligned.

 > The alignment check is not necessary ?free? in MD code ? a
 > mis-aligned address would likely trigger an alignment fault (SIGBUS
 > code path) rather than a page fault (SIGSEGV code path) in the trap
 > handler.  Certainly, it didn?t seem like the alpha trap handler
 > handled a misaligned address in this case at all.  This isn?t the
 > end of the world, but it means putting ?onfault? logic in more than
 > one code path in the trap handler.

The ones I remember looking at (which is not all of them, and probably
not alpha) didn't test onfault until they got to we_re_toast, meaning
any fault is already covered. But in any event it's free at runtime
(the sense of free I meant) because you only get to it when a trap
would otherwise be triggering a panic.

It's only not free on architectures where there are special
instructions for accessing usermode and they need to be explicitly
checked for failure rather than using on-fault logic; in that case you
might also need an explicit alignment check to avoid allowing bad
pointers to trigger a panic. That check should be in the MD code for
such ports. (If there even are any... I think there exist machines
that work this way, not sure we run on any of them.) 

-- 
David A. Holland
dholland%netbsd.org@localhost