summaryrefslogtreecommitdiff
path: root/lib/scudo/scudo_allocator_secondary.h
AgeCommit message (Collapse)Author
2017-12-06[scudo] Correct performance regression in SecondaryKostya Kortchinsky
Summary: This wasn't noticed: `RoundUpTo` doesn't produce a constant expression, so the sizes were not constant either. Enforce them to be static const, replace `RoundUpTo` by its expression. The compiler can now optimize the associated computations accordingly. Also looking at the produced assembly, `PageSize` was fetched multiple times during `Allocate`, so keep a local value of it. As a result it's fetched once and kept in a register. Reviewers: alekseyshl, flowerhack Reviewed By: alekseyshl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40862 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@319903 91177308-0d34-0410-b5e6-96231b3b80d8
2017-11-13[sanitizer] Update scudo to use new APIKostya Kortchinsky
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
2017-11-08[sanitizer] Add Scudo to the sanitizer lint checks.Kostya Kortchinsky
Summary: Scudo abides by the coding style enforced by the sanitizer_common linter, but as of right now, it's not linter-enforced. Add Scudo to the list of directories checked by check_lint.sh. Also: fixes some linter errors found after getting this running. Reviewers: cryptoad Reviewed By: cryptoad Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D39757 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@317699 91177308-0d34-0410-b5e6-96231b3b80d8
2017-06-20[Sanitizers] Move cached allocator_may_return_null flag to sanitizer_allocatorAlex Shlyapnikov
Summary: Move cached allocator_may_return_null flag to sanitizer_allocator.cc and provide API to consolidate and unify the behavior of all specific allocators. Make all sanitizers using CombinedAllocator to follow AllocatorReturnNullOrDieOnOOM() rules to behave the same way when OOM happens. When OOM happens, turn allocator_out_of_memory flag on regardless of allocator_may_return_null flag value (it used to not to be set when allocator_may_return_null == true). release_to_os_interval_ms and rss_limit_exceeded will likely be moved to sanitizer_allocator.cc too (later). Reviewers: eugenis Subscribers: srhines, kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D34310 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@305858 91177308-0d34-0410-b5e6-96231b3b80d8
2017-05-11[scudo] Use our own combined allocatorKostya Kortchinsky
Summary: The reasoning behind this change is twofold: - the current combined allocator (sanitizer_allocator_combined.h) implements features that are not relevant for Scudo, making some code redundant, and some restrictions not pertinent (alignments for example). This forced us to do some weird things between the frontend and our secondary to make things work; - we have enough information to be able to know if a chunk will be serviced by the Primary or Secondary, allowing us to avoid extraneous calls to functions such as `PointerIsMine` or `CanAllocate`. As a result, the new scudo-specific combined allocator is very straightforward, and allows us to remove some now unnecessary code both in the frontend and the secondary. Unused functions have been left in as unimplemented for now. It turns out to also be a sizeable performance gain (3% faster in some Android memory_replay benchmarks, doing some more on other platforms). Reviewers: alekseyshl, kcc, dvyukov Reviewed By: alekseyshl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33007 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302830 91177308-0d34-0410-b5e6-96231b3b80d8
2017-04-20[scudo] Minor changes and refactoringKostya Kortchinsky
Summary: This is part of D31947 that is being split into several smaller changes. This one deals with all the minor changes, more specifically: - Rename some variables and functions to make their purpose clearer; - Reorder some code; - Mark the hot termination incurring checks as `UNLIKELY`; if they happen, the program will die anyway; - Add a `getScudoChunk` method; - Add an `eraseHeader` method to ScudoChunk that will clear a header with 0s; - Add a parameter to `allocate` to know if the allocated chunk should be filled with zeros. This allows `calloc` to not have to call `GetActuallyAllocatedSize`; more changes to get rid of this function on the hot paths will follow; - reallocate was missing a check to verify that the pointer is properly aligned on `MinAlignment`; - The `Stats` in the secondary have to be protected by a mutex as the `Add` and `Sub` methods are actually not atomic; - The software CRC32 function was moved to the header to allow for inlining. Reviewers: dvyukov, alekseyshl, kcc Reviewed By: dvyukov Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32242 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@300846 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-13Corrected D27428: Do not use the alignment-rounded-up size with secondaryKostya Kortchinsky
Summary: I atually had an integer overflow on 32-bit with D27428 that didn't reproduce locally, as the test servers would manage allocate addresses in the 0xffffxxxx range, which led to some issues when rounding addresses. At this point, I feel that Scudo could benefit from having its own combined allocator, as we don't get any benefit from the current one, but have to work around some hurdles (alignment checks, rounding up that is no longer needed, extraneous code). Reviewers: kcc, alekseyshl Subscribers: llvm-commits, kubabrecka Differential Revision: https://reviews.llvm.org/D27681 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@289572 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-09Reverting rL289088 while investigating some test issue on the build serversKostya Kortchinsky
Subscribers: kubabrecka Differential Revision: https://reviews.llvm.org/D27605 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@289180 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-08[sanitizer] Do not use the alignment-rounded-up size when using the secondaryKostya Kortchinsky
Summary: The combined allocator rounds up the requested size with regard to the alignment, which makes sense when being serviced by the primary as it comes with alignment guarantees, but not with the secondary. For the rare case of large alignments, it wastes memory, and entices unnecessarily large fields for the Scudo header. With this patch, we pass the non-alignement-rounded-up size to the secondary, and adapt the Scudo code for this change. Reviewers: alekseyshl, kcc Subscribers: llvm-commits, kubabrecka Differential Revision: https://reviews.llvm.org/D27428 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@289088 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-30[scudo] 32-bit and hardware agnostic supportKostya Kortchinsky
Summary: This update introduces i386 support for the Scudo Hardened Allocator, and offers software alternatives for functions that used to require hardware specific instruction sets. This should make porting to new architectures easier. Among the changes: - The chunk header has been changed to accomodate the size limitations encountered on 32-bit architectures. We now fit everything in 64-bit. This was achieved by storing the amount of unused bytes in an allocation rather than the size itself, as one can be deduced from the other with the help of the GetActuallyAllocatedSize function. As it turns out, this header can be used for both 64 and 32 bit, and as such we dropped the requirement for the 128-bit compare and exchange instruction support (cmpxchg16b). - Add 32-bit support for the checksum and the PRNG functions: if the SSE 4.2 instruction set is supported, use the 32-bit CRC32 instruction, and in the XorShift128, use a 32-bit based state instead of 64-bit. - Add software support for CRC32: if SSE 4.2 is not supported, fallback on a software implementation. - Modify tests that were not 32-bit compliant, and expand them to cover more allocation and alignment sizes. The random shuffle test has been deactivated for linux-i386 & linux-i686 as the 32-bit sanitizer allocator doesn't currently randomize chunks. Reviewers: alekseyshl, kcc Subscribers: filcab, llvm-commits, tberghammer, danalbert, srhines, mgorny, modocache Differential Revision: https://reviews.llvm.org/D26358 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@288255 91177308-0d34-0410-b5e6-96231b3b80d8
2016-10-26[scudo] Lay the foundation for 32-bit supportKostya Kortchinsky
Summary: In order to support 32-bit platforms, we have to make some adjustments in multiple locations, one of them being the Scudo chunk header. For it to fit on 64 bits (as a reminder, on x64 it's 128 bits), I had to crunch the space taken by some of the fields. In order to keep the offset field small, the secondary allocator was changed to accomodate aligned allocations for larger alignments, hence making the offset constant for chunks serviced by it. The resulting header candidate has been added, and further modifications to allow 32-bit support will follow. Another notable change is the addition of MaybeStartBackgroudThread() to allow release of the memory to the OS. Reviewers: kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25688 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@285209 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-30[scudo] Fix an edge case in the secondary allocatorKostya Kortchinsky
Summary: s/CHECK_LT/CHECK_LE/ in the secondary allocator, as under certain circumstances Ptr + Size can be equal to MapEnd. This edge case was not found by the current tests, so those were extended to be able to catch that. Reviewers: kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25101 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@282913 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-29Don't use internal symbolizer if we are in process of reporting Out-of-Memory.Vitaly Buka
Reviewed by eugenis offline, as reviews.llvm.org is down. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@282805 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-20[scudo] Fix a bug in the new Secondary AllocatorKostya Kortchinsky
Summary: GetActuallyAllocatedSize() was not accounting for the last page of the mapping being a guard page, and was returning the wrong number of actually allocated bytes, which in turn would mess up with the realloc logic. Current tests didn't find this as the size exercised was only serviced by the Primary. Correct the issue by subtracting PageSize, and update the realloc test to exercise paths in both the Primary and the Secondary. Reviewers: kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24787 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@282030 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-19[scudo] Modify Scudo to use its own Secondary AllocatorKostya Kortchinsky
Summary: The Sanitizer Secondary Allocator was not entirely ideal was Scudo for several reasons: decent amount of unneeded code, redundant checks already performed by the front end, unneeded data structures, difficulty to properly protect the secondary chunks header. Given that the second allocator is pretty straight forward, Scudo will use its own, trimming all the unneeded code off of the Sanitizer one. A significant difference in terms of security is that now each secondary chunk is preceded and followed by a guard page, thus mitigating overflows into and from the chunk. A test was added as well to illustrate the overflow & underflow situations into the guard pages. Reviewers: kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24737 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@281938 91177308-0d34-0410-b5e6-96231b3b80d8