Revert "ANDROID: mm/slab: Create 64-byte slab caches if the hardware supports it"

This reverts commit 8a7073c1.

When the size passed to a kmalloc() call is not known at compile time,
__kmalloc() is invoked to satisfy the allocation request. __kmalloc()
is tagged with the __assume_aligned compiler attribute, with a value
of ARCH_KMALLOC_MINALIGN, which means that pointers returned by
__kmalloc() are guaranteed to be aligned to ARCH_KMALLOC_MINALIGN.

For ARM64, ARCH_KMALLOC_MINALIGN is defined as 128 bytes. However,
when the android_kmalloc_64_create command line parameter is used,
the assumption that pointers from __kmalloc() are aligned to 128 bytes
is no longer true, as allocations can be satisfied from the 64 byte slab
caches, and those objects would be 64 byte aligned.

This inconsistency between the runtime behavior of __kmalloc() and
the expected behavior of __kmalloc() that was established at compile
time, can lead to a pointer from __kmalloc() being operated on
incorrectly.

Consider the following case:

static void foo() {

unsigned long buf_offset;
u8 *data_buf = __kmalloc();

...

buf_offset = offset_in_page(data_buf)
}

Assuming a 4 KB page size, the offset_in_page() macro should compile to
just:

data_buf & 0xfff

However, an examination of the code that the Clang compiler emits
revealed that the offset_in_page() operation in this case evaluates to:

data_buf & 0xf80

This occurs because the code for offset_in_page() is inlined into the
body of foo, which obtains a pointer directly from invoking __kmalloc().
When deciding what constant to use to calculate the offset into the
page, the compiler can use its knowledge of the alignment of pointers
from __kmalloc() to generate a mask that may be more optimal for
further operations (note that the mask that is used--0xf80--is just
0xfff aligned to 128 bytes).

The scenario described above is problematic if a buffer that was
allocated through kmalloc is 64-byte aligned, as the offset of the
buffer into the page will be calculated incorrectly, which can cause
inconsistencies about where the start of the buffer is (e.g. when
DMA-mapping buffers for peripherals).

Thus, remove support for android_kmalloc_64_create to avoid creating
this mismatch in the behavior of __kmalloc().

Bug: 288214403
Bug: 291097092
Change-Id: Ie22df9f5918253d23b8c2a0c0d64f54a710b0514
[isaacmanjarres: keeping the android_kmalloc_64_create variable to
preservethe KMI.]
Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>