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
This commit adds libhidlmemory.so and android.hidl.memory@1.0.so to the
exported libs of the `vndk` linker namespace (aka. VNDK-SP). This is
necessary because some vendors' GLES implementation uses
libhidlmemory.so. Check http://b/35107583#comment15 for the context.
Bug: 35107583
Test: sailfish boots
Merged-In: Idb5ba4ed4a89795e0e6105d55a84e7f6bbffff51
Change-Id: I1556b7499bd981af995f000519b7a314c70567d1
This commit adds libhidlmemory.so and android.hidl.memory@1.0.so to the
exported libs of the `vndk` linker namespace (aka. VNDK-SP). This is
necessary because some vendors' GLES implementation uses
libhidlmemory.so. Check http://b/35107583#comment15 for the context.
Bug: 35107583
Test: sailfish boots
Merged-In: Idb5ba4ed4a89795e0e6105d55a84e7f6bbffff51
Merged-In: I1556b7499bd981af995f000519b7a314c70567d1
Change-Id: I5af7c954d432a2e8de6c6b744cedbada836bbd98
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
Merged-In: I4a6ff043eb7115b729ca4954ebc6c9e000132993
Change-Id: I4a6ff043eb7115b729ca4954ebc6c9e000132993
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 device_init() 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 device_init() 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: Boot hikey + hotplug/unplug sdcard
Merged-In: I21636355d8e434f30e0cba568598a6cf139e67f9
Change-Id: I21636355d8e434f30e0cba568598a6cf139e67f9
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
