diff options
author | Bin Lu <bin.lu@arm.com> | 2020-06-02 04:25:32 -0400 |
---|---|---|
committer | Bin Lu <bin.lu@arm.com> | 2020-09-30 11:54:37 +0800 |
commit | 45221684f3e3d985f91a1a896cac616c537516e2 (patch) | |
tree | 86953f12d03a8bb7d6e1e9cb1c922ce8f52c49ab /test/syscalls/linux | |
parent | 4b5eae39f201ffbe7f4a0e08a28380099469efe8 (diff) |
avoid the random memory barrier issue in mmap testing on Arm64
There is a new random issue on some Arm64 machines.
This scene can be summarized as following:
Sometimes, the content of the func() pointer is still 0 opcode.
The probability of this kind of issue is very low,
currently only available on some machines.
After inserting a simple memory barrier, this issue was gone.
The code to directly use the memory barrier is as follows:
memcpy(reinterpret_cast<void*>(addr), machine_code, sizeof(machine_code));
isb()
func = reinterpret_cast<uint32_t (*)(void)>(addr);
Signed-off-by: Bin Lu <bin.lu@arm.com>
Diffstat (limited to 'test/syscalls/linux')
-rw-r--r-- | test/syscalls/linux/mmap.cc | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/test/syscalls/linux/mmap.cc b/test/syscalls/linux/mmap.cc index 6d3227ab6..a523ce189 100644 --- a/test/syscalls/linux/mmap.cc +++ b/test/syscalls/linux/mmap.cc @@ -589,6 +589,11 @@ TEST_F(MMapTest, ProtExec) { memcpy(reinterpret_cast<void*>(addr), machine_code, sizeof(machine_code)); +#if defined(__aarch64__) + // We use this as a memory barrier for Arm64. + ASSERT_THAT(Protect(addr, kPageSize, PROT_READ | PROT_EXEC), SyscallSucceeds()); +#endif + func = reinterpret_cast<uint32_t (*)(void)>(addr); EXPECT_EQ(42, func()); |