| Age | Commit message (Collapse) | Author |
|---|
|
Summary:
See D40657 & D40679 for previous versions of this patch & description.
A couple of things were fixed here to have it not break some bots.
Weak symbols can't be used with `SANITIZER_GO` so the previous version was
breakin TsanGo. I set up some additional local tests and those pass now.
I changed the workaround for the glibc vDSO issue: `__progname` is initialized
after the vDSO and is actually public and of known type, unlike
`__vdso_clock_gettime`. This works better, and with all compilers.
The rest is the same.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, kubamracek, krytarowski, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D41121
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@320594 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary: D40679 broke a couple of builds, reverting while investigating.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, kubamracek, krytarowski, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D41088
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@320417 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
allocator [redo]
Summary:
Redo of D40657, which had the initial discussion. The initial code had to move
into a libcdep file, and things had to be shuffled accordingly.
`NanoTime` is a time sink when checking whether or not to release memory to
the OS. While reducing the amount of calls to said function is in the works,
another solution that was found to be beneficial was to use a timing function
that can leverage the vDSO.
We hit a couple of snags along the way, like the fact that the glibc crashes
when clock_gettime is called from a preinit_array, or the fact that
`__vdso_clock_gettime` is mangled (for security purposes) and can't be used
directly, and also that clock_gettime can be intercepted.
The proposed solution takes care of all this as far as I can tell, and
significantly improve performances and some Scudo load tests with memory
reclaiming enabled.
@mcgrathr: please feel free to follow up on
https://reviews.llvm.org/D40657#940857 here. I posted a reply at
https://reviews.llvm.org/D40657#940974.
Reviewers: alekseyshl, krytarowski, flowerhack, mcgrathr, kubamracek
Reviewed By: alekseyshl, krytarowski
Subscribers: #sanitizers, mcgrathr, srhines, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D40679
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@320409 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Now that the sanitizer_common interface for MmapNoAccess / MmapFixed
have been refactored to allow a more OO-esque access pattern, update the
Fuchsia mmap implementation to take advantage of this.
Previously MmapNoAccess / MmapFixed relied on a global allocator_vmar,
since the sanitizer_allocator only called MmapNoAccess once. Now, we
create a new VMAR per ReservedAddressRange object.
This allows the sanitizer allocator to work in tandem with the Scudo
secondary allocator.
This is part 4 of a 4 part changeset:
* part 1 https://reviews.llvm.org/D38593
* part 2 https://reviews.llvm.org/D38592
* part 3 https://reviews.llvm.org/D38593
Reviewers: mcgrathr, cryptoad
Reviewed By: cryptoad
Subscribers: alekseyshl, mcgrathr, kubamracek, mehdi_amini
Differential Revision: https://reviews.llvm.org/D38595
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@319083 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change allows Fuchsia to boot properly using the Scudo allocator.
A first version of this commit was reverted by rL317834 because it broke Android
builds for toolchains generated with older NDKs. This commit introduces a
fall back to solve that issue.
Reviewers: cryptoad, krytarowski, rnk, alekseyshl
Reviewed By: cryptoad, krytarowski, alekseyshl
Subscribers: llvm-commits, srhines, kubamracek, krytarowski
Differential Revision: https://reviews.llvm.org/D40121
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@318802 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change reverts r318575 and changes FindDynamicShadowStart() to
keep the memory range it found mapped PROT_NONE to make sure it is
not reused. We also skip MemoryRangeIsAvailable() check, because it
is (a) unnecessary, and (b) would fail anyway.
Reviewers: pcc, vitalybuka, kcc
Subscribers: srhines, kubamracek, mgorny, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D40203
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@318666 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Revert the following commits:
r318369 [asan] Fallback to non-ifunc dynamic shadow on android<22.
r318235 [asan] Prevent rematerialization of &__asan_shadow.
r317948 [sanitizer] Remove unnecessary attribute hidden.
r317943 [asan] Use dynamic shadow on 32-bit Android.
MemoryRangeIsAvailable() reads /proc/$PID/maps into an mmap-ed buffer
that may overlap with the address range that we plan to use for the
dynamic shadow mapping. This is causing random startup crashes.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@318575 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
The ScudoAllocator uses a SecondaryHeader to keep track of the size and base address of each mmap'd chunk.
This aligns well with what the ReservedAddressRange is trying to do. This changeset converts the scudo allocator from using the MmapNoAccess/MmapFixed APIs to the ReservedAddressRange::Init and ::Map APIs. In doing so, it replaces the SecondayHeader struct with the ReservedAddressRange object.
This is part 3 of a 4 part changeset; part 1 https://reviews.llvm.org/D39072 and part 2 https://reviews.llvm.org/D38592
Reviewers: alekseyshl, mcgrathr, cryptoad, phosek
Reviewed By: cryptoad
Subscribers: llvm-commits, cryptoad, kubamracek
Differential Revision: https://reviews.llvm.org/D38593
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@318080 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
The following kernel change has moved ET_DYN base to 0x4000000 on arm32:
https://marc.info/?l=linux-kernel&m=149825162606848&w=2
Switch to dynamic shadow base to avoid such conflicts in the future.
Reserve shadow memory in an ifunc resolver, but don't use it in the instrumentation
until PR35221 is fixed. This will eventually let use save one load per function.
Reviewers: kcc
Subscribers: aemerson, srhines, kubamracek, kristof.beyls, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D39393
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@317943 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This reverts D39490.
For toolchains generated with older NDKs (<=r13b as far as we tested),
`cpu_set_t` doesn't exist in `sched.h`.
We have to figure out another way to get the number of CPUs without this.
Reviewers: rnk
Reviewed By: rnk
Subscribers: kubamracek, llvm-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D39867
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@317834 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary: This change allows Fuchsia to boot properly using the Scudo allocator.
Reviewers: cryptoad, alekseyshl, krytarowski
Reviewed By: cryptoad, krytarowski
Subscribers: rnk, krytarowski, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D39490
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@317822 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts commit r317604.
Android doesn't have cpu_set_t.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@317655 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Future change will introduce GetMaxVirtualAddress that will not take
the kernel area into account.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@317638 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary: This change allows Fuchsia to boot properly using the Scudo allocator.
Reviewers: cryptoad, alekseyshl, krytarowski
Reviewed By: cryptoad, krytarowski
Subscribers: krytarowski, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D39490
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@317604 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Update sanitizer_allocator to use new API.
Second patch in a series. First patch https://reviews.llvm.org/D39072
Updates MmapNoAccess / MmapFixed call sites in the saniziter_allocator
to use the new Init/Map APIs instead.
Reviewers: alekseyshl, cryptoad, phosek, mcgrathr, dvyukov
Reviewed By: alekseyshl, cryptoad
Subscribers: dvyukov, mcgrathr, kubamracek
Differential Revision: https://reviews.llvm.org/D38592
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@317586 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary: Fixes https://reviews.llvm.org/D39072
Reviewers: cryptoad
Reviewed By: cryptoad
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D39427
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@316943 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary: This should fix the Windows bots after D39072.
Reviewers: alekseyshl, flowerhack
Reviewed By: flowerhack
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D39426
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@316937 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Fixed version of https://reviews.llvm.org/D38437 (fixes Win/Fuchsia failures).
Creating a new revision, since the old one was getting a bit old/crowded.
In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global
VMAR, which means that MmapNoAccess can only be called once. This works
for the sanitizer allocator but *not* for the Scudo allocator.
Hence, this changeset introduces a new ReservedAddressRange object to
serve as the new API for these calls. In this changeset, the object
still calls into the old Mmap implementations.
The next changeset two changesets will convert the sanitizer and scudo
allocators to use the new APIs, respectively. (ReservedAddressRange will
replace the SecondaryHeader in Scudo.)
Finally, a last changeset will update the Fuchsia implementation.
Reviewers: alekseyshl, cryptoad, phosek
Reviewed By: alekseyshl, cryptoad
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D39072
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@316934 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
There are two instances of -Wcast-qual and one of -Wsign-compare.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@316930 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
sanitizer_common""
The SanitizerCommon.ReservedAddressRangeUnmap test fails on Windows:
FAIL: SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test.exe/SanitizerCommon.ReservedAddressRangeUnmap (34003 of 35554)
******************** TEST 'SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test.exe/SanitizerCommon.ReservedAddressRangeUnmap' FAILED ********************
Note: Google Test filter = SanitizerCommon.ReservedAddressRangeUnmap
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from SanitizerCommon
[ RUN ] SanitizerCommon.ReservedAddressRangeUnmap
==3780==ERROR: SanitizerTool failed to deallocate 0x1000 (4096) bytes at address 0x0000000c3000 (error code: 487)
==3780==Sanitizer CHECK failed: E:\b\build\slave\win_upload_clang\build\src\third_party\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_win.cc:129 (("unable to unmap" && 0)) != (0) (0, 0)
********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 299.76s
********************
Failing Tests (1):
SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test.exe/SanitizerCommon.ReservedAddressRangeUnmap
> In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global
> VMAR, which means that MmapNoAccess can only be called once. This works
> for the sanitizer allocator but *not* for the Scudo allocator.
>
> Hence, this changeset introduces a new ReservedAddressRange object to
> serve as the new API for these calls. In this changeset, the object
> still calls into the old Mmap implementations.
>
> The next changeset two changesets will convert the sanitizer and scudo
> allocators to use the new APIs, respectively. (ReservedAddressRange will
> replace the SecondaryHeader in Scudo.)
>
> Finally, a last changeset will update the Fuchsia implementation.
>
> Patch by Julia Hansbrough
>
> Differential Revision: https://reviews.llvm.org/D38437
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@315553 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global
VMAR, which means that MmapNoAccess can only be called once. This works
for the sanitizer allocator but *not* for the Scudo allocator.
Hence, this changeset introduces a new ReservedAddressRange object to
serve as the new API for these calls. In this changeset, the object
still calls into the old Mmap implementations.
The next changeset two changesets will convert the sanitizer and scudo
allocators to use the new APIs, respectively. (ReservedAddressRange will
replace the SecondaryHeader in Scudo.)
Finally, a last changeset will update the Fuchsia implementation.
Patch by Julia Hansbrough
Differential Revision: https://reviews.llvm.org/D38437
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@315533 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts commit r315493 which is failing to build on sanitizer-windows.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@315494 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global
VMAR, which means that MmapNoAccess can only be called once. This works
for the sanitizer allocator but *not* for the Scudo allocator.
Hence, this changeset introduces a new ReservedAddressRange object to
serve as the new API for these calls. In this changeset, the object
still calls into the old Mmap implementations.
The next changeset two changesets will convert the sanitizer and scudo
allocators to use the new APIs, respectively. (ReservedAddressRange will
replace the SecondaryHeader in Scudo.)
Finally, a last changeset will update the Fuchsia implementation.
Patch by Julia Hansbrough
Differential Revision: https://reviews.llvm.org/D38759
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@315493 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Adds a fallback mode to procmaps when the symbolizer
fails to locate a module for a given address by using
dl_iterate_phdr.
Reviewers: kubamracek, rnk, vitalybuka, eugenis
Reviewed By: eugenis
Subscribers: srhines, llvm-commits
Differential Revision: https://reviews.llvm.org/D37269
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314713 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts commit r314671, which hangs on the gcc sanitizer buildbot.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314684 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Adds a fallback mode to procmaps when the symbolizer
fails to locate a module for a given address by using
dl_iterate_phdr.
Reviewers: kubamracek, rnk, vitalybuka, eugenis
Reviewed By: eugenis
Subscribers: srhines, llvm-commits
Differential Revision: https://reviews.llvm.org/D37269
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314671 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Unreverting this patch because llvm-clang-lld-x86_64-debian-fast started
passing again before the revert hit. Must've been just a flake.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314556 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I think this may have introduced a failure on
llvm-clang-lld-x86_64-debian-fast
This reverts commit r314533
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314552 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314533 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This causes the gcc sanitizer buildbot to timeout.
This reverts commit 81f388fe570e5b6460dd5bc9b9a36b72714eeb68.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314453 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Adds a fallback mode to procmaps when the symbolizer
fails to locate a module for a given address by using
dl_iterate_phdr.
Reviewers: kubamracek, rnk, vitalybuka, eugenis
Reviewed By: eugenis
Subscribers: srhines, llvm-commits
Differential Revision: https://reviews.llvm.org/D37269
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314431 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This broke the windows buildbots, revert for now.
This reverts commit 24050b5ddef42f6f3306aa94d4a1f42a7893a9a7.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314347 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Change-Id: I5594bd6b216deca2c73cf0a7001f9aec1e803c60
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314342 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
defined
Summary:
Platforms that don't implement procmaps (primarily fuchsia and windows) still expose
the procmaps API when including sanitizer_procmaps.h, despite not implementing the functions
provided by that header. Ensure that the API is only exposed on platforms that implement it.
Reviewers: vitalybuka, alekseyshl, kubamracek
Subscribers: llvm-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D38187
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314149 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313518 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313240 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313227 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313224 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Reviewers: eugenis, alekseyshl
Subscribers: kubamracek, dberris
Differential Revision: https://reviews.llvm.org/D37827
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313223 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary: Part of https://github.com/google/sanitizers/issues/637
Reviewers: eugenis, alekseyshl, filcab
Subscribers: kubamracek, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D37793
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313168 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Information stored there is often been passed along with SignalContext.
Part of https://github.com/google/sanitizers/issues/637
Reviewers: eugenis, alekseyshl
Subscribers: kubamracek, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D37792
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313167 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
On platforms with `getrandom`, the system call defaults to blocking. This
becomes an issue in the very early stage of the boot for Scudo, when the RNG
source is not set-up yet: the syscall will block and we'll stall.
Introduce a parameter to specify that the function should not block, defaulting
to blocking as the underlying syscall does.
Update Scudo to use the non-blocking version.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D36399
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@310839 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This is a pure refactoring change. It just moves code that is
related to filesystem operations from sanitizer_common.{cc,h} to
sanitizer_file.{cc,h}. This makes it cleaner to disable the
filesystem-related code for a new port that doesn't want it.
Submitted on behalf of Roland McGrath.
Reviewers: kcc, eugenis, alekseyshl
Reviewed By: alekseyshl
Subscribers: vitalybuka, llvm-commits, kubamracek, mgorny, phosek
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35591
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@308819 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
On iOS/AArch64, the address space is very limited and has a dynamic maximum address based on the configuration of the device. We're already using a dynamic shadow, and we find a large-enough "gap" in the VM where we place the shadow memory. In some cases and some device configuration, we might not be able to find a large-enough gap: E.g. if the main executable is linked against a large number of libraries that are not part of the system, these libraries can fragment the address space, and this happens before ASan starts initializing.
This patch has a solution, where we have a "backup plan" when we cannot find a large-enough gap: We will restrict the address space (via MmapFixedNoAccess) to a limit, for which the shadow limit will fit.
Differential Revision: https://reviews.llvm.org/D35098
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@307865 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Make SizeClassAllocator64 return nullptr when it encounters OOM, which
allows the entire sanitizer's allocator to follow
allocator_may_return_null=1 policy
(LargeMmapAllocator: D34243, SizeClassAllocator64: D34433).
Reviewers: eugenis
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34540
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@306342 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Make SizeClassAllocator32 return nullptr when it encounters OOM, which
allows the entire sanitizer's allocator to follow allocator_may_return_null=1
policy, even for small allocations (LargeMmapAllocator is already fixed
by D34243).
Will add a test for OOM in primary allocator later, when
SizeClassAllocator64 can gracefully handle OOM too.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34433
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@305972 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
AFAICT compiler-rt doesn't have a function that would return 'good' random
bytes to seed a PRNG. Currently, the `SizeClassAllocator64` uses addresses
returned by `mmap` to seed its PRNG, which is not ideal, and
`SizeClassAllocator32` doesn't benefit from the entropy offered by its 64-bit
counterpart address space, so right now it has nothing. This function aims at
solving this, allowing to implement good 32-bit chunk randomization. Scudo also
has a function that does this for Cookie purposes, which would go away in a
later CL once this lands.
This function will try the `getrandom` syscall if available, and fallback to
`/dev/urandom` if not.
Unfortunately, I do not have a way to implement and test a Mac and Windows
version, so those are unimplemented as of now. Note that `kRandomShuffleChunks`
is only used on Linux for now.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: zturner, rnk, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34412
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@305922 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Context: https://github.com/google/sanitizers/issues/740.
Making secondary allocator to respect allocator_may_return_null=1 flag
and return nullptr when "out of memory" happens.
More changes in primary allocator and operator new will follow.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34243
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@305569 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This broke thread_local_quarantine_pthread_join.cc on some architectures, due
to the overhead of the stashed regions. Reverting while figuring out the best
way to deal with it.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34213
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@305404 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
The reasoning behind this change is explained in D33454, which unfortunately
broke the Windows version (due to the platform not supporting partial unmapping
of a memory region).
This new approach changes `MmapAlignedOrDie` to allow for the specification of
a `padding_chunk`. If non-null, and the initial allocation is aligned, this
padding chunk will hold the address of the extra memory (of `alignment` bytes).
This allows `AllocateRegion` to get 2 regions if the memory is aligned
properly, and thus help reduce fragmentation (and saves on unmapping
operations). As with the initial D33454, we use a stash in the 32-bit Primary
to hold those extra regions and return them on the fast-path.
The Windows version of `MmapAlignedOrDie` will always return a 0
`padding_chunk` if one was requested.
Reviewers: alekseyshl, dvyukov, kcc
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34152
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@305391 91177308-0d34-0410-b5e6-96231b3b80d8
|
