This just takes the regular non-atomic unit tests and changes them to
have lock prefixes.
These are all handled as byte sized atomics so there aren't any
alignment problems.
Base size is now only one page in size. We will then increment that BRK
size by 8MB alignments. 256MB for 32bit applications was causing some
applications on the edge to run out of virtual memory
I was hitting some 32bit applications that were being fairly mean with
BRK. They were allocating all of BRK space then running out of virtual
memory space with its mmap handler fallback after freeing BRK space.
This means we now munmap BRK pages on release for the guest, similar to
behaviour that Linux does.
Additionally I had an application that was getting very upset that BRK
wasn't actually at the end of program space. So allocate at the end of
program space like expected.
brk test now passes from gvisor
The glibc and kernel timer interfaces are sufficiently different enough
that unwrapping this through glibc is impossible.
Pass it directly through to the kernel.
cmpxchg/cmpxchg8b doesn't have alignment requirements on x86, which means
applications rely on unaligned behaviour support with it.
Steam relies on this to work for a linked list array of jobs in some
internal job queueing system. It will end up always aligning by offsets
of 4 since it stores a couple of pointers.
Doesn't currently support the case of unaligned cmpxchg8b crossing a
cacheline, which ends up being semi-broken depending on which x86
behaviour the application is expected.
Intel CPUs do the "Big ring lock" or "split locks". Which means accesses
across cachelines are atomic.
AMD CPUs will tear the value across the cacheline, which is expected x86
behaviour by spec.
If they are expecting Intel behaviour, then that application is just
broken on non-Intel platforms unless they are fine with a tear.
killpg has been causing us testing problems for a while now.
As we were running more tests it was becoming more likely to hit a test
doing killpg in the background.
All of the tests run under the same process group so it is a significant
race condition to have these running.
Until we improve CI to somehow work around how killpg works, we just
need to have these disabled.
