This test should be testing how the kernel should behave, not how
it actually (used to) behave when it was incorrect...  Aside from
a possible EPERM (which is not tested) the only error possible from
mlock() is ENOMEM.  POSIX also allows EINVAL if the address is not
page aligned and the implementation does not round down to the previous
page boundary, but NetBSD does.

The kernel was recently fixed to return the correct errors for mlock()
so now we really need the test to be checking them, and not expecting
the incorrect errno values that the kernel used to return.

Same for munlock() - there ENOMEM is the only possible error, again,
EINVAL cannot happen as the kernel rounds to page boundaries.
For munlock() the kernel has not yet been corrected (that is coming
real soon...) and one of the munlock() tests will currently fail
(as of the time this commit is made, hopefully not for much longer)
as it should - it is indicating a kernel bug.

Note that NetBSD mlock(2) talks about EINVAL for cases where the length
parameter is negative ... but that is a size_t - good luck having that
ever occur (the man page will soon be corrected as well.)

(kre)