The purpose of those tests is to ensure fsync succeeds for
directories. However, they try to call fsync for / (the root
filesystem) that is usually mounted read-only, which does not
make sense because the whole point of fsync is to flush
uncommitted changes to the filesystem.
In fact, some well-known read-only filesystems (e.g. squashfs)
does not support fsync, so these tests fail if we use such
filesystems as the root filesystem.
This patch changes the tests to call fsync against /data
instead. /data is a user data partition and should be always
mounted read-write.
Bug: 28681455
(cherry picked from commit cfa3262ce4)
Change-Id: I3e50f7b6ef07e96138711eef1f678f90cc9eb632
This CL adds initialization of inode for the main executable
which enables linker to resolve the correct soinfo when
application calls dlopen with absolute path to the
main executable.
Bug: http://b/28420266
Change-Id: I102e07bde454bd44c6e46075e3faeeb5092830d8
This change enables apps to share libraries opened
with RTLD_GLOBAL between different classloader namespaces.
The new parameter to create_namespace allows native_loader
to instruct the linker to share libraries belonging to
global group from a specified namespace instead of
using the caller_ns.
Bug: http://b/28560538
Bug: https://code.google.com/p/android/issues/detail?id=208458
Change-Id: I5d0c62730bbed19cdeb16c7559c74aa262a2475f
They are intended for platform use only and we shouldn't have them
in the public header file.
Bug: http://b/28174921
Change-Id: Ib9b3d0fa9442cfa2e784a693ad567d1444d774e5
* Allow clone where both the child function and stack are null. It's
obviously wrong to ask to call a function without a stack, but it's not
necessarily wrong to supply no stack if you're also not supplying a
function.
* Reimplement fork in terms of the clone function, rather than using the
clone system call directly.
This is intended as a step towards enabling use of pid namespaces.
Change-Id: I03c89bd1dc540d8b4ed1c8fdf6644290744b9e91
http://clang.llvm.org/docs/AttributeReference.html#nonnull
_Nonnull is similar to the nonnull attribute in that it will instruct
compilers to warn the user if it can prove that a null argument is
being passed. Unlike the nonnull attribute, this annotation indicated
that a value *should not* be null, not that it *cannot* be null, or
even that the behavior is undefined. The important distinction is that
the optimizer will perform surprising optimizations like the
following:
void foo(void*) __attribute__(nonnull, 1);
int bar(int* p) {
foo(p);
// The following null check will be elided because nonnull
// attribute means that, since we call foo with p, p can be
// assumed to not be null. Thus this will crash if we are called
// with a null pointer.
if (src != NULL) {
return *p;
}
return 0;
}
int main() {
return bar(NULL);
}
Note that by doing this we are no longer attaching any sort of
attribute for GCC (GCC doesn't support attaching nonnull directly to a
parameter, only to the function and naming the arguments
positionally). This means we won't be getting a warning for this case
from GCC any more. People that listen to warnings tend to use clang
anyway, and we're quickly moving toward that as the default, so this
seems to be an acceptable tradeoff.
Change-Id: Ie05fe7cec2f19a082c1defb303f82bcf9241b88d
Future API levels aren't known (e.g. 25 could be a maintenance release
of N that doesn't contain any bionic updates), so use a placeholder
macro that we can find and replace with the actual API level before each
release.
Bug: http://b/28178111
Change-Id: I667fe53ea1ac49b64135170fc30d5dbe9df94e29
Some symbols appeared at different times between 32 and 64 bit. Add a
macro to represent this.
Bug: http://b/28178111
Change-Id: I0aa46d9da3c7301b60df0416bce252f0f37b7b36
complex_test.cpp is compiled with both bionic and glibc, so when
__INTRODUCED_IN starts being used in <complex.h>, we'll need this to
keep it building.
Bug: http://b/28178111
Change-Id: I6431111be35288cad72e9c23ca8599f548b6d906
* Fix the return type of towlower_l/towupper_l.
* Implement wctrans/wctrans_l/towctrans/towctrans_l.
* Move declarations that POSIX says are available from both <wchar.h> and
<wctype.h> to <bits/wctype.h> and include from both POSIX headers.
* Write the missing tests.
Change-Id: I3221da5f3d7e8a2fb0a7619dc724de45f7b55398
Not efficient to iterate through given the large number of Android
ids (AID). Compile warning will result if you use these functions,
telling you as much. Not for general consumption, however for
example, some filesystem tests would like to see these to perform
all corners.
About 1/4 second for getpwent, and 1/8 second for getgrent to iterate
through all reserved Android aids.
Bug: 27999086
Change-Id: I7784273b7875c38e4954ae21d314f35e4bf8c2fc
This adds a test which verifies that watchpoints work on devices
which support them. It is motivated by issues experienced by Nexus
5 devices, where watchpoints work only sporadically.
These tests spawn a process, trace it, and verify it hits a
watchpoint of various sizes while executing on all available CPUs
(to help catch a recent bug, where some debugging functionality
was not available on non-boot CPUs). All x86(_64) targets are
expected to support this functionality. In case of arm(64),
watchpoints are expected to work on devices where the relevant
syscall indicates watchpoint presence. In case of mips, this test
is skipped as I could not verify that the test would work
correctly due to lack of hardware, and this test is intrinsically
hardware-dependend.
Change-Id: I035ac1822816cd1a3f3b56b985c2fb5fd664185d
linker didn't remove link to the soinfo from shared
namespaces on soinfo_unload, because it didn't keep
record of all namespaces the library is added to.
This change adds test for this and also fixes the
problem by introducing list of secondary namespaces
to soinfo, which is used to remove soinfo in
soinfo::remove_all_links().
Bug: http://b/28115950
Change-Id: Ifbf6e54f92fa6e88f86b6a8dd6dc22d4553afd22
Even though bionic linker does not support RTLD_LAZY - it
is good to know that its behavior matches glibc.
Bug: http://b/27930475
Change-Id: I1a47263aaa3dc44f9ac61fe77deb55a21e7f881a
The XXXX now lines up to the underlying uid and has no offset.
Work with AID_OEM_RESERVED uids.
Test uses hard coded values to catch changes in the API expectations
that may occur in private/android_filesystem_config.h.
SideEffects: names change, some product dependencies.
Bug: 27999086
Change-Id: Ic2b4c36de74ae009a44e14711c75834293828207
This was fixed upstream years ago. While we're here, let's switch to the
OpenBSD copy (because that's our majority upstream BSD, not because they
found and fixed this bug first).
Bug: http://b/28035006
Change-Id: I53dd915a8122bfd7a6d58f01f9902d1586a47e23
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
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>
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
Previously, the implementation of setjmp on x86_64 claimed that
sigprocmask would write to two longs' worth of bytes.
Bug: http://b/27856501
Change-Id: I9f32b40ac773a0cd91a976aace5bfba6e67fb0f8
Handle no longer is a pointer to soinfo of
a corresponding library. This is done to
prevent access to linker internal fields.
Bug: http://b/25593965
Change-Id: I62bff0d0e5b2dc842e6bf0babb30fcc4c000be24
