- User Since
- May 5 2016, 2:57 PM (140 w, 5 d)
Wed, Dec 19
Tue, Dec 18
Dec 10 2018
Oct 31 2018
FYI, regarding -fsanitize-minimal-runtime it's also used for Scudo to link the lib that doesn't include RTUBsan & the symbolizer & stacktraces RT.
Oct 23 2018
There is a check for real_clock_gettime (as an extern "C", not part of the interception namespace) in MonotonicNanoTime, as defined by sanitizer_common_interceptors.inc, can this check be moved there? eg: if real_clock_gettime exists & the interception function is not null?
Oct 2 2018
Sep 27 2018
Alright let's go with this one for the sake of HWasan.
Sep 26 2018
For reference, see comments in https://reviews.llvm.org/D52279#1246222
Or maybe replace the CHECK there with a Trap?
Sep 25 2018
I am actually gonna have to work on the numbers again.
I ran into some issues with the Quarantine. If the Quarantine is low or off, then the numbers are good because we keep reusing the recently freed chunks.
But when the Quarantine is enabled, then have a low amount of cached pointers is detrimental.
Sep 21 2018
Sep 20 2018
Sep 19 2018
Sep 18 2018
Do not update base_ & size_ to reflect the fact that the reserved range
remains unchanged. Adding a comment to clarify that partial unmapping still
leaves the memory reserved.
Correct a comment to reflect that it is the destruction of the vmar that is
responsible for the unmapping.
Skip the UnmapOrDieVmar call when unmapping the whole mapping, as
vmar_destroy will take care of this. We still have to do some bookkeeping
Some before & after numbers for one of the benchmarks involved:
1552377 207294 1121659 2214385 1550481 nanoseconds N/A Thread/CreateAndJoin 451883 35547 374475 984192 448331 nanoseconds N/A Thread/CreateAndJoin
Aug 29 2018
Reverting the initial patch with D51451.
Could I please get a LGTM and/or other options so that I can try and fix the aarch64 bots?
Aug 28 2018
Link to test source: https://github.com/llvm-mirror/compiler-rt/blob/master/test/msan/mmap.cc#L78
Last test output: 0xf00000000
Link to msan mmap interceptor: https://github.com/llvm-mirror/compiler-rt/blob/master/lib/msan/msan_interceptors.cc#L939
Aug 24 2018
Aug 23 2018
LGTM with a nit.
Additional question but that doesn't require changes to the CL: if you have a ByteMap it means you are using the SizeClassAllocator32 in 64-bit mode (it's gated by a define, look for SANITIZER_CAN_USE_ALLOCATOR64).
Have you tried using the SizeClassAllocator64?
You probably can add as well the couple others that default to true that could be set to false as well:
Aug 20 2018
Updated proposal: make Mmap*NoAccess return nullptr on failure (like the
other Mmap functions).
Modify callers that were checking for ~(uptr)0 to now check for nullptr.
Other wrong use:
hwasan::MapDynamicShadow: checks for failure with ~(uptr)0 (while it's the syscall return value)
asan::FindDynamicShadowStart: same as above
__asan::PremapShadow: same as above
I guess after scavenging further, my initial patch is not correct, as other functions return nullptr on failure.
I am open to anything if we can get a consensus on what should be returned.
Aug 18 2018
Aug 17 2018
Aug 14 2018
Aug 13 2018
Grammar/punctuation corrections in comments.
Account for 0 size, which is more common than one would expect.
Aug 10 2018
Aug 9 2018
Random thought: isn't the introduction of malloc here (as opposed to an OS backed alternative like mmap) gonna mess compatibility with other Sanitizers that intercept it? (thinking of Scudo which is currently compatible with SafeStack but I haven't tested).