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.

address comments

Could you add a test?

.

address comments

address comments

I've merged two earlier changes (gwp-asan re-enablement and atfork/enable/disable support) in one because they are interconnected.

See https://reviews.llvm.org/D73294

See https://reviews.llvm.org/D73294

rebase

rebase

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).

LGTM

LGTM, thank you!

LGTM

friendly ping

FWIW I'm ok with this landing in the previous version, disabling GWP-ASan, because its integration in scudo is so broken right now.

LGTM

I'm concerned about the removal of gwp-asan.
Could you check if https://reviews.llvm.org/D72546 helps?

This is meant to go on top of

https://reviews.llvm.org/D72470

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.

LGTM

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?

Updated a comment.
Renamed "old" STGloop instructions to STGloop_wback, and new ones to STGloop.

Fixed the tied use of a non-register problem by introducing _untied versions to STGloop pseudos for use with a FrameIndex operand.

In D72364#1810619, @cryptoad wrote:

In D72364#1810596, @eugenis wrote:

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.

I think the second approach is more keen to "if allocator is disabled when we call fork, wait until it's enabled", as opposed to disabling it pre-fork.

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.

This revision and its two dependencies improve MTE code size of chromium on aarch64-linux-android by slightly more than 1%.

In D71780#1806823, @vitalybuka wrote:

what is about clang-format?

Addressed review comments and most of the clang-tidy findings.

clang-format

PTAL

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

https://reviews.llvm.org/D72023

https://reviews.llvm.org/D72024