The move to async safe logging in I3d3b2111f6f6bf8a0d7039295d34d5168c191651
caused MEM_ALOGV messages to print even when NDEBUG was set.
Test: builds
Change-Id: Ibebe69d8c96f8f2556991c1eb5446a77782d43c7
Putting libmemunreachable in the global C++ namespace was an oversight,
move it into namespace android.
Test: m -j checkbuild
Change-Id: I0799906f6463178cb04a719bb4054cad33a50dbe
* changes:
Revert "Revert "init: poll in first stage mount if required devices are not found""
Revert "Revert "ueventd: remove PlatformDeviceList""
fs_mgr: differentiate if fs_mgr_set_verity() was skipped or disabled
In case of non-secure builds (eng variant) fs_mgr_setup_verity() skips
verity checks regardless of fstab options. This is slightly different
than 'adb disable-verity' where it would first read the verity metadata
to check if verity is disabled.
So, this change adds a new return value of FS_MGR_SETUP_VERITY_SKIPPED
instead of piggy backing on the FS_MGR_SETUP_VERITY_DISABLED.
Bug: 62864413
Test: Boot sailfish
Change-Id: I42bf2bdce0ecb18b4c3b568e2bc96bf1590dfb35
Signed-off-by: Sandeep Patil <sspatil@google.com>
The only case where tombstoned creates files for java traces is
when the process is signalled "by hand" using "shell kill -3", or
by the program itself. Such traces do not correspond to an ANR, so
name those files "trace_XX".
When dumpstate / system_server want to dump java traces, they set up
a tombstoned intercept and manage the lifetime of any associated file
that themselves.
Bug: 32064548
Test: manual, debuggerd_test
Change-Id: I97006ec7c0cd35de4b9564f535e77af846cc3891
Example:
signal 5 (SIGTRAP), code -32763 (PTRACE_EVENT_STOP), fault addr 0x274e00005fb3
I'm tempted to say that %d isn't the best choice for si_code, but as long as
we're fully decoding all the values, I don't think it matters.
Bug: http://b/62856172
Test: manual debuggerd run
Change-Id: Ieeca690828e1e12f4162bbadece53f4aa7b9537a
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
