Somewhere between kernel 5.15 and 6.0 this syscall's behaviour has
changed.
The unit test expects -ESPIPE result but new kernels will return 0
(noop_llseek in the source).
The new solidrun board is our first CI machine to be running kernel 6.1
so this needs to be merged before that CI machine can be enabled.
This has a badly coded test that can hang forever. Our timeout kills it
at 5 minutes, which causes it to not even fall down the flake path.
Just disable it outright because of the bad test.
If a test is marked as a flake then it will be tried five times before
giving up.
Works around the problem of needing to babysit CI once a PR is pushed.
As long as we have all the flake tests marked.
cmake will bake in the environment variable in to the build scripts.
Instead have the guest_test_runner fetch it at runtime.
This means if you forget to set ROOTFS prior to running cmake, you can
now set it afterwards and rerun with just ctest instead of a cmake
dance.
Fixes#315
Depending on runner this passes or fails.
The test expects to be able to open `/proc/self/oom_score_adj` as writable to adjust the oom score.
This is expected to fail on all three of our runners, but sometimes the solidrun board manages to open it.
Disable as it is a flake. Could be a kernel bug on the solid run board
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.
