- User Since
- Oct 3 2012, 3:00 AM (381 w, 5 d)
Fri, Jan 24
Hm, we should really fix that sometime soon.
fix lint warnings
AFAIK we do test on android.
See http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android/builds/27148/steps/run%20lit%20tests%20%5Baarch64%2Faosp_marlin-userdebug%2FPI%5D/logs/stdio - it lists a few scudo tests as unsupported, which means the rest of them have passed.
Could you add a test?
Thu, Jan 23
I've merged two earlier changes (gwp-asan re-enablement and atfork/enable/disable support) in one because they are interconnected.
Wed, Jan 22
Tue, Jan 21
Fallback to a different allocator is hard, because then you need to implement PointerIsMine to redirect to the right allocator in free(), and AFAIK we don't have that in scudo for the larger allocations (i.e. secondary).
Fri, Jan 17
LGTM, thank you!
Thu, Jan 16
Wed, Jan 15
Mon, Jan 13
FWIW I'm ok with this landing in the previous version, disabling GWP-ASan, because its integration in scudo is so broken right now.
I'm concerned about the removal of gwp-asan.
Could you check if https://reviews.llvm.org/D72546 helps?
Fri, Jan 10
This is meant to go on top of
with the cmake bits that disable GWP-ASan reverted.
remove a ton of unrelated changes
Removed scudo+gwp_asan tests.
Added fork support to gwp_asan and associated tests.
I'm not sure this is a good idea after all.
We'd need to also bump sampling rate to 1 for reliable testing, and that does not work with scudo tests which specifically test the scudo implementation, and not a random posix-compliant allocator.
Please update all the other implementations of internal_mmap
OFF_T magic is about matching libc.so ABI in the interceptors.
internal_mmap does not have to deal with it, and it can simply use uptr for the offset argument, unless I'm missing something.
SCUDO_PREFIX(Mutex) can be acquired in the child process, and in the parent process, and is not held during fork. That's a potential deadlock.
The condvar code reduces the window for it, but does not eliminate it completely.
Why can't malloc_disable() simply directly call allocator.disable(), and the same in malloc_enable?
Thu, Jan 9
Updated a comment.
Renamed "old" STGloop instructions to STGloop_wback, and new ones to STGloop.
Wed, Jan 8
Fixed the tied use of a non-register problem by introducing _untied versions to STGloop pseudos for use with a FrameIndex operand.
I see. I think the other approach could be safer. Grab all the locks before fork and release them after fork. This will also allow user applications to use malloc after fork, which ex. glibc allocator supports.
Could we do this exact same thing in Android? I find this behavior (auto-enabling the allocator after fork) unexpected, and it makes the interface even more confusing then it is now.
Tue, Jan 7
This revision and its two dependencies improve MTE code size of chromium on aarch64-linux-android by slightly more than 1%.
Mon, Jan 6
Addressed review comments and most of the clang-tidy findings.
Thu, Jan 2
Cleaned up the code and extended it to allow gaps in a sequence of memory tagging instructions (in which case subsequences before and after the gap would be optimized separatly).
Should be fixed in 3e5eac03580
reworded the comment
tighten the test with CHECK-NOT