[scudo][standalone] Reduce Android region sizes to 128MB

[cryptoad]

Summary

Unity is making irresponsible assumptions as to how clumped up memory
should be. With larger regions, we break those, resulting in errors
like:

"Using memoryadresses from more that 16GB of memory"

This is unfortunately one of those situations where we have to bend to
existing code because we doubt it's going to change any time soon.

128MB should be enough, but we could be flirting with OOMs in the
higher class sizes.

[merge_guards_bot]

Unit tests: fail. 62080 tests passed, 1 failed and 784 were skipped.

failed: Clang.Driver/cc-print-options.c

clang-tidy: unknown.

clang-format: pass.

Build artifacts: diff.json, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

[hctim]

This is unfortunately one of those situations where we have to bend to
existing code because we doubt it's going to change any time soon.

:'(

Apparently this was fixed in Unity 5.4.1 (feedback post only available on WaybackArchive). You can see the patchnotes here which mentions: Linux: Removed 16GB total memory limit..

Instead of bending to old apps, could we consider potentially gating either a Scudo specific config, or Scudo in general (over jemalloc) on AppCompat platform version? We are doing this for Tagged Pointers currently in an attempt not to break old apps. The former seems like a much better option, as the latter requires us to maintain jemalloc on Android for the foreseeable future to use as a fallback allocator for old apps.

[eugenis]

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

This is terrible, but what can you do.

LGTM

[pcc]

In D73143#1832560, @eugenis wrote:

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

If we really wanted to do this, maybe we could use one of the TBI bits (bit 60-63 so as not to collide with MTE) to mark the allocation as belonging to the new allocator.

compiler-rt/lib/scudo/standalone/allocator_config.h

 #endif
   typedef MapAllocator<> Secondary;
   template <class A> using TSDRegistryT = TSDRegistryExT<A>; // Exclusive
 };
 
 struct AndroidConfig {
   using SizeClassMap = AndroidSizeClassMap;
 #if SCUDO_CAN_USE_PRIMARY64
-  // 1GB regions
-  typedef SizeClassAllocator64<SizeClassMap, 30U,
+  // 128MB regions
+  typedef SizeClassAllocator64<SizeClassMap, 27U,
                                /*MaySupportMemoryTagging=*/true>
       Primary;
 #else
   // 512KB regions
   typedef SizeClassAllocator32<SizeClassMap, 19U> Primary;
 #endif
   typedef MapAllocator<> Secondary;
   template <class A>
   using TSDRegistryT = TSDRegistrySharedT<A, 2U>; // Shared, max 2 TSDs.
 };
 
 struct AndroidSvelteConfig {
   using SizeClassMap = SvelteSizeClassMap;
 #if SCUDO_CAN_USE_PRIMARY64
-  // 512MB regions
-  typedef SizeClassAllocator64<SizeClassMap, 29U> Primary;
+  // 128MB regions
+  typedef SizeClassAllocator64<SizeClassMap, 27U> Primary;
 #else
   // 64KB regions
   typedef SizeClassAllocator32<SizeClassMap, 16U> Primary;
 #endif
   typedef MapAllocator<0U> Secondary;
   template <class A>
   using TSDRegistryT = TSDRegistrySharedT<A, 1U>; // Shared, only 1 TSD.
 };