It turns out that at least the Nexus 9 kernel is built without CONFIG_QUOTA.
If we decide we're going to mandate quota functionality, I'm happy for us to
be a part of CTS that ensures that happens, but I don't want to be first, so
there's not much to test here other than "will it compile?". The strace
output looks right though.
Bug: http://b/27948821
Bug: http://b/27952303
Change-Id: If667195eee849ed17c8fa9110f6b02907fc8fc04
- added grp_pwd.cpp containing POSIX passwd and group functions,
colocated because they share with the Android ID (AID) roots.
- stubs.cpp contains all the truly empty functions (network and
protocol accessors)
Bug: 27999086
Change-Id: I036f9e2dd246f48302cb7c97d23176fa24d19c33
Add missing test for sleb128_decoder. Also remove
dependency to static library because it exposes malloc/free
which interfere with libc.so malloc/free causing test to crash.
Change-Id: Iedd3268011df9f67ed58c0b58c71f34e30370b23
Collect statistics about DNS query success state and delay. Ignore
servers that have been tried at least five times and have a success rate
of < 0.25. Retry these servers once every 180s.
Bug: 25731675
Change-Id: I78e24f43e388dca82fb81835e1796f4c7dce8da3
Implement the legacy SysV signal handling functions sighold(),
sigignore(), sigpause(), sigrelse(), and sigset() in terms of the newer
POSIX signal APIs. As of POSIX 2013 the SysV signal APIs are deprecated
but still required.
Change-Id: I4ca40e3d706605a7d1a30dc76c78b2b24586387d
Signed-off-by: Greg Hackmann <ghackmann@google.com>
The code to calculate thread stack and signal stack looks weird:
the thread stack size and signal stack size are related with
each other on 32-bit mode, but not on 64-bit mode. So change the
code to make the logic more resonable. This doesn't change anything
as we have defined SIGSTKSZ to 16K on arm64.
Bug: 28005110
Change-Id: I04d2488cfb96ee7e2d894d062c66cef950fec418
This function only exists for backwards compatibility, so leave it as it was.
Bug: http://b/26944282
Change-Id: I31973d1402660933103ee2d815649ab9569e4dfc
Any caller of brk needs to handle failure by falling back to mmap as
there's no guarantee that other mappings are not placed above the brk
heap. Since jemalloc starts with mmap in the first place and dlmalloc
knows how to fall back to mmap, it's already a legacy API in Android.
Forcing it to succeed rules out stronger ASLR implementations where the
brk heap might not have any room to grow. It's also valid for the brk
implementation to simply return -1 with errno set to ENOMEM in every
case and that's a good way of finding anything relying on it. It would
make sense for it to be an optional kernel feature.
The brk heap is also not guaranteed to be initially page aligned. PaX
ASLR randomizes the internal bits. It was only mentioned in a comment to
explain the design of the test though.
Bug: 24233096
Change-Id: I16e9bc8677e796c73915b830b99b0ce39c02b31d
The compiler in master doesn't leave a gap between the buffer and the stack
guard canary.
Bug: http://b/27815668
Change-Id: Iae6681683881055c2719d661a2179f5305c23135
Built for fugu this was working fine, but built for generic x86/x86-64
the compiler was (a) optimizing out all the stack writes and (b) inserting
enough padding on x86-64 for the canary to be safely out of the way.
While here, let's tighten up this test so we test that it's sufficient to
only overwrite the buffer by one byte...
(cherry-pick of 6f90c1ac59eb4e7811b7b0e408615049c935c0a9.)
Bug: http://b/27815668
Change-Id: I80a646de4b30fd5c78df20fdaa7e3eb163585caf
MIPS still have ld128 and 16-bit atomics issues with clang, so we can't
just remove this yet.
Bug: http://b/25291096
Change-Id: I2645ebf3af04e1a4008d70da780c04240e3d7a85
Josh Gao
Elliott Hughes
Mark Salyzyn
Pierre Imai
Dimitry Ivanov
Yabin Cui
Greg Hackmann
Dan Willemsen
Nick Kralevich
Daniel Micay