All tests for our recent CursorWindow changes have been passing for
ARM 64-bit builds, but they weren't executed against 32-bit x86
builds until after merged.
It's not actually safe to use the "off_t" type, so we need to cast
to "int32_t" when doing checks against possible-negative values,
such as in allocRow().
We also add tests that verify negative rows/columns are identified
as invalid positions, which requires that we check the resulting
pointer against both mSlotsEnd and mSlotsStart.
Bug: 169251528, 171276404, 171275409
Test: atest libandroidfw_tests:CursorWindowTest
Test: atest CtsDatabaseTestCases
Change-Id: Iea5f7546850f691e183fbb6e6d0952cd02b00d0f
We recently rewrote CursorWindow, so let's get a fuzzer wired up
to see if it has any bugs.
This change creates a separate "libandroidfw_fuzz" library, since we
can't link to libbinder when building Windows host-side binaries;
the fuzzer doesn't need Window support.
And fix our first vulnerability where getFieldSlot() could be
tricked into reading out of bounds data.
The included corpus seed was generated using this example code:
CursorWindow* w = nullptr;
CursorWindow::create(android::String8("test"), 1 << 21, &w);
w->setNumColumns(3);
w->allocRow();
w->putLong(0,0,0xcafe);
w->putLong(0,1,0xcafe);
w->putLong(0,2,0xcafe);
// Row purposefully left empty
w->allocRow();
w->allocRow();
w->putNull(2,0);
w->putNull(2,1);
w->putNull(2,2);
w->allocRow();
w->putString(3,0,"cafe",5);
w->putString(3,1,"cafe",5);
w->putString(3,2,"cafe",5);
w->allocRow();
w->putDouble(4,0,3.14159f);
w->putDouble(4,1,3.14159f);
w->putDouble(4,2,3.14159f);
Parcel p;
w->writeToParcel(&p);
Bug: 169251528
Test: atest libandroidfw_tests:CursorWindowTest
Test: SANITIZE_HOST=address make ${FUZZER_NAME} && ${ANDROID_HOST_OUT}/fuzz/$(get_build_var HOST_ARCH)/${FUZZER_NAME}/${FUZZER_NAME}
Change-Id: I405d377900943de0ad732d3f1a1a0970e17d5140
The original CursorWindow implementation was created in Android 1.0
and has remained relatively unchanged since then. Unfortunately that
design results in very poor performance on large windows, since
reading or writing each FieldSlot is O(row/100) to traverse through
a chain of RowSlotChunks. It's also memory-inefficient due to how
it allocates RowSlotChunks in 404 byte chunks, even when there's only
a single row to store.
This change is a complete redesign of the CursorWindow internals to
use a "heap-and-stack" style approach, where a "heap" of strings
and blobs increment up from the bottom of the window while a "stack"
of FieldSlots increment down from the top of the window.
The included benchmarks show the following improvements, ensuring
no regressions for small windows, while offering very dramatic
improvements for larger windows:
Big cores Little cores
4x4 cursor no regression no regression
1024x4 cursor 2.2x faster 2.0x faster
16384x4 cursor 48.5x faster 24.4x faster
Detailed unit testing is also included to ensure that the rewrite
behaves correctly.
Bug: 169251528
Test: atest libandroidfw_tests
Test: atest CtsDatabaseTestCases
Test: atest FrameworksCoreTests:android.database
Test: ./frameworks/base/libs/hwui/tests/scripts/prep_generic.sh little && atest libandroidfw_benchmarks
Test: ./frameworks/base/libs/hwui/tests/scripts/prep_generic.sh little && atest CorePerfTests:android.database.CrossProcessCursorPerfTest
Change-Id: I90dff31fd550130dae917a33e0e1fa684e15c107
Currently each CursorWindow allocates a 2MiB ashmem region to store
data, but this ends up being quite wasteful since the majority of
windows only end up storing a small handful of rows/columns. In
addition, creating and mmap'ing these ashmem regions requires
acquiring the mmap semaphore in the kernel, which can significantly
impact P95/P99 metrics when the system is under heavy load.
To mitigate the issues described above, this change adjusts
CursorWindow to send small windows (under 16KiB in size) directly
inline in Parcel responses without requiring an ashmem region.
CursorWindows also offer to gracefully "inflate" themselves into an
ashmem region when filled with more than 16KiB of data. This
requires some bugfixes around alloc() call sites to ensure that any
pointers are converted to offsets during a potential inflation.
The benchmarks referenced below show the following improvements
after this change is applied:
* Small cursor (1 row): 36% performance improvement
* Medium cursor (100 rows): no difference
* Large cursor (10k rows): no difference
Bug: 169251528
Test: atest CtsDatabaseTestCases
Test: atest FrameworksCoreTests:android.database
Test: ./frameworks/base/libs/hwui/tests/scripts/prep_generic.sh little && atest CorePerfTests:android.database.CrossProcessCursorPerfTest
Change-Id: Ie0fd149299f9847bf59a39f2855ed201bca4cdf6
Params of size_t use %zu formatting, while int64_t use PRId64. These
params had not been updated in a while since LOG_WINDOW is a no-op
macro when LOG_NDEBUG is off.
Test: Enable LOG_NDEBUG and do make
Change-Id: I59e9fa1aa343fd0a1da83c40fd24f3ef7bae5ed4
Replace calls to dup() with fcntl(F_DUPFD_CLOEXEC). The only difference
between the two is that O_CLOEXEC is set on the newly duped file
descriptor. This helps address file descriptor leaks crossing an exec()
boundary.
Test: compiles and boots
Bug: 120983106
Change-Id: Icc2ff2f7f398905aa8283c8797898114d34a9829
Check whether specified offset belongs to mData.
Also added a default argument bufferSize to check the end offset.
Size of the ashmem descriptor can be modified between
ashmem_get_size_region call and mmap. createFromParcel method was updated
to check ashmem size again immediately after memory is mapped.
Test: manual - using the test app from the bug
Bug: 34128677
Change-Id: I3ecd1616a870ce20941ce9b20a1843d2b4295750
Changes in this patch include
[x] Use %zu for size_t, %zd for ssize_t
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
Change-Id: Id1aaa7894a7d0b85ac7ecd7b2bfd8cc40374261f
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
No longer compile libandroidfw as a static library on the device
since it already exists as a shared library. Keeping the static
library would force us to provide a static library version of
libinput for the device as well which doesn't make sense.
Change-Id: I3517881b87b47dcc209d80dbd0ac6b5cf29a766f
