We already know that there are no free blocks above Region->AllocatedUser.
This results in a smaller RegionPageMap and faster releaseFreeMemoryToOS.
Patch By: fabio-d
Differential Revision: https://reviews.llvm.org/D138794
Try to trigger an MTE fault on double/invalid free by touching the first
byte of the allocation with the provided pointer.
Differential Revision: https://reviews.llvm.org/D137352
In SizeClassAllocator64, the boundary of a memory group may not align to
the region begin. Which means the begin addr of a memory group may
smaller than region begin. This leads to wrong judgement of memory group
usage.
Differential Revision: https://reviews.llvm.org/D136898
We allocate the page map before knowing if there're groups can be
released. This may result in many redundant map()/unmap() operations if
there's no page to release.
Make the page map be lazy initialized.
Differential Revision: https://reviews.llvm.org/D136873
In SizeClassAllocator64, the RegionBeg is determined by RegionBase +
random offset. The offset is n pages, where n is a random number less or
equal to 16. However, on certain platforms which have large page size,
it may end up immediately OOM without mapping any block pages. For
example,
PageSize = 64 KB, RegionSize = 1 MB
Suppose the random number n is 16, then the random offset will be
64 * 16 = 1024 KB which is equal to the RegionSize.
On most platforms we don't have such large page size and we have
different PRNG(pseudo random number generator) behaviors, thus we didn't
hit any failures before. Given that this now only affects the tests,
only increase the region size is enough.
Will revisit the logic of calculating the random offset.
Differential Revision: https://reviews.llvm.org/D136025
u16 may be promoted to int by arithmetic type conversion. Do an explicit
cast to avoid certain compiler's warning. This fixes the problem
introduced by 0fb2aeef53
Differential Revision: https://reviews.llvm.org/D135985
u16 may be promoted to int by arithmetic type conversion. Do an explicit
cast to avoid certain compiler's warning.
Differential Revision: https://reviews.llvm.org/D135945
Block grouping enables us doing partial page releasing so that we can
release the pages in a finer granularity. Which means we don't need to
visit all blocks to determine which pages are unused. Besides, this
means we can do incremental page releasing depends on the number fo free
blocks.
Reviewed By: cryptoad, cferris
Differential Revision: https://reviews.llvm.org/D134226
Scudo is supposed to allocate any blocks across the entired mapped
pages and each page is equally likely to be selected. Which means Scudo
is leaning to touch as many pages as possible. This brings better
security but it also sacrifices the chance of releasing dirty pages.
To alleviate the unmanagable footprint growing, this CL introduces the
BatchGroup concept. Each blocks will be classified into a BatchGroup
according to its address. While allocation, we are leaning to allocate
blocks in the same group first. Note that the blocks selected from a
group is still random over several pages. At the same time, we have
better prediction of dirty page growing speed. Besides, we are able to
do partial page releasing by examing part of BatchGroups.
Reviewed By: cryptoad, cferris
Differential Revision: https://reviews.llvm.org/D133897
PageReleaseContext contains all the information needed for determing if
a page can be released. Splitting out the context increases the flexibility
of heterogenous free lists in the future. Also rename PackedCounterArray to
PageMap.
Reviewed By: cryptoad, cferris
Differential Revision: https://reviews.llvm.org/D133895
The Count/MaxCount used in TransferBatch and PerClass can be fit in u16 in
current configurations and it's also reasonable to have a u16 limit. The
spare 16 bits will be used for additional status like pages mapping
status in a TransferBatch.
Reviewed By: cryptoad, cferris, vitalybuka
Differential Revision: https://reviews.llvm.org/D133145
These options will allow the SCUDO standalone to be built with custom
headers. Specifically, this patch will enable building with the
LLVM-libc headers.
Reviewed By: abrachet
Differential Revision: https://reviews.llvm.org/D135702
When in-tree libcxx is selected as the sanitizer C++ ABI, use
libcxx-abi-* targets rather than libcxxabi and libunwind directly.
Differential Revision: https://reviews.llvm.org/D134855
It casued some runtimes builds to fail with cmake error
No target "libcxx-abi-static"
see code review.
> When in-tree libcxx is selected as the sanitizer C++ ABI, use
> libcxx-abi-* targets rather than libcxxabi and libunwind directly.
>
> Differential Revision: https://reviews.llvm.org/D134855
This reverts commit 414f9b7d2f.
When in-tree libcxx is selected as the sanitizer C++ ABI, use
libcxx-abi-* targets rather than libcxxabi and libunwind directly.
Differential Revision: https://reviews.llvm.org/D134855
When linking scudo standalone on armv7, it can't find symbols related to
unwinding (e.g. __aeabi_unwind_cpp_pr0). This is because it is passing
--unwindlib=none. This patch hacks around the issue by adding
COMPILER_RT_UNWINDER_LINK_LIBS to the link line.
I don't know anything about scudo, so I'm not sure what the original
intention was.
See also https://github.com/llvm/llvm-project/issues/56900
Differential Revision: https://reviews.llvm.org/D131250
We already link libunwind explicitly so avoid trying to link toolchain's
default libunwind which may be missing. This matches what we already do
for libcxx and libcxxabi.
Differential Revision: https://reviews.llvm.org/D129472
After https://reviews.llvm.org/D129237, the assumption
that any non-null data contains a valid vmar handle is no
longer true. Generally this code here needs cleanup, but
in the meantime this fixes errors on Fuchsia.
Differential Revision: https://reviews.llvm.org/D129331
This is a follow up to D118200 which applies a similar cleanup to
headers when using in-tree libc++ to avoid accidentally picking up
the system headers.
Differential Revision: https://reviews.llvm.org/D128035
This is a follow up to D118200 which applies a similar cleanup to
headers when using in-tree libc++ to avoid accidentally picking up
the system headers.
Differential Revision: https://reviews.llvm.org/D128035
This allows configuring LLVM unwinder separately from the C++ library
matching how we configure it in libcxx.
This also applies changes made to libunwind+libcxxabi+libcxx in D113253
to compiler-rt.
Differential Revision: https://reviews.llvm.org/D115674
This keeps the test behavior unchanged when CLANG_DEFAULT_PIE_ON_LINUX switches
to ON by default.
Note: current clang --target=mips64el-linux-gnu -fpie -pie -fuse-ld=lld
does not link with C++ exceptions, using -pie would lead to
```
ld.lld: error: cannot preempt symbol: DW.ref.__gxx_personality_v0
...
ld.lld: error: relocation R_MIPS_64 cannot be used against local symbol; recompile with -fPIC
...
```
when linking `ScudoUnitTests`: https://lab.llvm.org/buildbot/#/builders/169/builds/7311/steps/18/logs/stdio
Update the hardware CRC32 logic in scudo to support using `-mcrc32`
instead of `-msse4.2`. The CRC32 intrinsics use the former flag
in the newer compiler versions, e.g. in clang since 12fa608af4.
With these versions of clang, passing `-msse4.2` is insufficient
to enable the instructions and causes build failures when `-march` does
not enable CRC32 implicitly:
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/scudo_crc32.cpp:20:10: error: always_inline function '_mm_crc32_u32' requires target feature 'crc32', but would be inlined into function 'computeHardwareCRC32' that is compiled without support for 'crc32'
return CRC32_INTRINSIC(Crc, Data);
^
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/scudo_crc32.h:27:27: note: expanded from macro 'CRC32_INTRINSIC'
# define CRC32_INTRINSIC FIRST_32_SECOND_64(_mm_crc32_u32, _mm_crc32_u64)
^
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/../sanitizer_common/sanitizer_platform.h:132:36: note: expanded from macro 'FIRST_32_SECOND_64'
# define FIRST_32_SECOND_64(a, b) (a)
^
1 error generated.
For backwards compatibility, use `-mcrc32` when available and fall back
to `-msse4.2`. The `<smmintrin.h>` header remains in use as it still
works and is compatible with GCC, while clang's `<crc32intrin.h>`
is not.
Use __builtin_ia32*() rather than _mm_crc32*() when using `-mcrc32`
to preserve compatibility with GCC. _mm_crc32*() are aliases
to __builtin_ia32*() in both compilers but GCC requires `-msse4.2`
for the former, while both use `-mcrc32` for the latter.
Originally reported in https://bugs.gentoo.org/835870.
Differential Revision: https://reviews.llvm.org/D122789
This reverts commit 09b53121c3.
Breaks the build with GCC 11.2 on x86_64:
In file included from /home/npopov/repos/llvm-project/compiler-rt/lib/scudo/scudo_crc32.h:27,
from /home/npopov/repos/llvm-project/compiler-rt/lib/scudo/scudo_crc32.cpp:14:
/usr/lib/gcc/x86_64-redhat-linux/11/include/smmintrin.h: In function ‘__sanitizer::u32 __scudo::computeHardwareCRC32(__sanitizer::u32, __sanitizer::uptr)’:
/usr/lib/gcc/x86_64-redhat-linux/11/include/smmintrin.h:846:1: error: inlining failed in call to ‘always_inline’ ‘long long unsigned int _mm_crc32_u64(long long unsigned int, long long unsigned int)’: target specific option mismatch
846 | _mm_crc32_u64 (unsigned long long __C, unsigned long long __V)
Petr Hosek