We can't implement MEM_LOG_ALWAYS_FATAL_IF any more, but it wasn't really
useful anyway.
Bug: N/A
Test: ran `crasher assert` and `crasher64 assert`
Change-Id: I4ae2d82fdfdd58cf8ef1dfb6c401cef4ba9d3e88
First stage mount in init currently attempts to regenerate uevents for
specific devices to create the corresponding dev nodes. However, this
is racy as first stage mount happens early in the boot process and
it's possible that some of these devices have not yet been created by
the kernel.
To fix this issue, init will poll on the uevent socket for up to 10
seconds waiting for the kernel to create the required device. It will
return false and panic if this 10 second timeout passes.
Note that the same uevent socket is used in the uevent regeneration
and the polling code, so there is no race if the device is created
after the uevent regeneration and before polling starts; the first
poll will pick up the device.
Bug: 62681642
Bug: 62682821
Test: Boot bullhead
Test: Boot sailfish
Test: Boot hikey + hotplug/unplug sdcard
Change-Id: I4a6ff043eb7115b729ca4954ebc6c9e000132993
In order to create symlinks for USB and block devices, the path for
their parent platform device must be known.
Previously, ueventd would save each platform device that it encounters
to a list and query this list when creating the symlinks. That,
however, is racy because the uevent socket does not differentiate
uevents from RegenerateUevents() and uevents sent by the kernel when
probing a device first the first time. The below scenario is the
faulty case:
1) Kernel probes parent platform device for a block device
2) ueventd calls RegenerateUevents() and starts processing uevents
3) Kernel probes block device and sends its uevents
4) ueventd picks up the block device uevent during its uevent processing,
without yet regenerating the platform device uevent, causing improper
symlinks to be created.
This change stops storing the platform devices in a list, and instead
traverses up the directory structure for each USB or block device
until it reaches a platform device, defined as one whose subsystem is
the platform bus. This fixes the race and simplifies the ueventd
code.
Bug: 62436493
Bug: 62681642
Test: Boot bullhead
Test: Boot sailfish
Test: Init unit tests
Test: Boot hikey + hotplug/unplug sdcard
Change-Id: I21636355d8e434f30e0cba568598a6cf139e67f9
It depends on functionality in the bionic
allocator, which may get updated independently
of the vendor partition (as libc is in the LL-NDK).
Bug: 33241851
Test: builds
Change-Id: I435679843229d0d4d2e2be7bfe8c27f558a016dd
Don't release the sender socket when FrameworkListener receives
a command that exceed the maximum buffer length
Bug: https://issuetracker.google.com/issues/62812018
Test: manual
Change-Id: I160f504f3fb902ba25fc79deb8ae7d78d811a807
ueventd already does restorecon() for /sys/{block,class,devices}, so
instead of duplicating this effort with init, move the restorecon()
that init does for all of /sys to ueventd.
Bug: 62420036
Change-Id: I6125f8ff5316a0cf45872d1100d089d71802958f
Merged-In: I6125f8ff5316a0cf45872d1100d089d71802958f
Test: Boot sailfish, bullhead
Fix a couple of memory leaks in tests.
Fix a potential case that length could be zero.
Bug: 23762183
Test: Ran unit tests, then ran valgrind on unit tests and verified no leaks.
Change-Id: I5f7602aa0204db0488a8e305250658cdb6e977d0
Make them available to tests so that they can compare values
directly instead of comparing error code strings.
Test: zip_archive_test
Change-Id: I1c78c24651ff7549b5125a49a4e67bbd8295c617
Relax the shell command length limits when talking to an adbd with the
shell protocol.
shell is pretty much the only service that takes an arbitrarily long
string, so this is somewhat safe.
Bug: http://b/37716055
Test: `adb shell $(python -c 'print "echo " + "f" * (32*1024)') | wc` on L and master
Change-Id: I0737fd2244530ef8080f300cd3a3549a1ab93465
restorecon_recursive may take a long time if there are a lot of files on
the volume. This can trigger a watchdog timeout in any process that
tries to set a property while it is running. Fix this by running
restorecon_recursive in its own process.
See https://jira.lineageos.org/browse/BUGBASH-555
Change-Id: I2ce26ff2b5bfc9a133ea42f4dbac50a3ac289c04
Commit 795267d4c7 ("Removed cpusets/schedboost build time dependency.")
turned the cpusets and schedtune options into runtime
decisions.
However the kernel option which is mentioned in the
code comment (CONFIG_SCHEDTUNE) is very misleading
as it doesn't exist (CONFIG_SCHED_TUNE does exist)
and it doesn't describe the real functionality of
the method. schedboost_enabled() will still return
false if CONFIG_SCHED_TUNE is set in the kernel but
CONFIG_CGROUP_SCHEDTUNE is not.
So to clarify this, we need to change the comment
to reflect that CONFIG_CGROUP_SCHEDTUNE, which depends
on CONFIG_SCHED_TUNE, is required.
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
Some files in libcore/tzdata are moving to system/timezone
under the package com.android.timezone.distro.
Bug: 31008728
Test: run cts -m CtsHostTzDataTests
Merged-In: I2600dd4bee22a571b9eb7303733591b60d1a8b2a
Change-Id: I2600dd4bee22a571b9eb7303733591b60d1a8b2a
Kernel can use vsyscall for system calls. The vsyscall implementation in
the kernel gives one more depth in the backtrace. It leads to failures
on CrasherTest. This CL makes tests find a system call frame not only in
the first line but also in all lines on the backtrace.
Bug: 62600694
Test: passes all CrasherTests.
Change-Id: Ice383bb94db097e7e9a9e4f74d8fa5ecc528122a
The get4LE method needs to use unsigned types since the sign char values
can lead to producing wrong values.
Bug: 62599757
Test: passes all test cases of logd-unit-tests.
Change-Id: Ifaf83533d847ea4fbe0cd46a978f4dabbfa7df8d
Bug: 38240024
Test: Verified that grep is installed in /vendor/bin. See details in
testing done comment in https://android-review.googlesource.com/412061 .
Change-Id: I06007014779310bc24c65f7343111c5217ba6ff0
- Ensure that the compressed and uncompressed lengths in the data
descriptor match those in the central directory.
- Calculate CRCs for compressed entries and ensure that those CRCs
match the information in the central directory / data descriptor.
This is currently guarded by a flag and will be turned on at a
later stage.
- Finally, always trust the LFH when it comes to indicating the
existence of a data descriptor. We no longer require this info to
match the central directory to bring this in line with other zip
processing tools. (see NOTE in the included change).
Bug: 62047801
Test: zip_archive_test
Change-Id: Icceea66a8b1937c08a4af9aee97bc77ad7218c0f
The Central File Header and Local File Header should
have the same general purpose bit flags set for
consistency.
Bug: 36686974
Test: existing tests pass (ziparchive-tests)
(cherry picked from commit 73b3aa541f)
Change-Id: Ia672a28732154a564ea2f2e3520238bb77924a56
The lib is used by libc_malloc_debug_backtrace which is
vendor_available. libc_malloc_debug_backtrace is marked as such because
it is again used by libmemunreachable which is vendor_available.
Bug: 33241851
Test: BOARD_VNDK_VERSION=current m -j libmemunreachable.vendor
Change-Id: I978f8e34d354e4fe03a3c19dd0dbc6899f26a793
