ueventd may be asked to handle firmware during the time critical
coldboot process. If we double fork to avoid needing to reap the
firmware handler, then we may add significant delay to this process,
as the first child may not get scheduled quickly enough for waitpid()
to complete without delay.
Bug: 63081260
Test: boot bullhead and sailfish, check that firmwares are loaded,
no zombie ueventd processes remain, and no new errors are shown
Change-Id: I2bac3b1fbc3a58557a00326e491c104656db27ae
- "shutdown critical" prevents killing the service during
shutdown. And the service will be started if not running.
- Without it, services will be killed by SIGTERM / SIGKILL during shutdown.
- Even services with "shutdown critical" will be killed if shutdown
times out.
- Removes ueventd and vold from hard coded list. Each service's rc will
be updated to add "shutdown critical". watchdogd is still kept in the list.
bug: 37626581
Test: reboot and check last kmsg
Change-Id: Ie8cc699d1efbc59b9a2561bdd40fec64aed5a4bb
We have been seeing panics and errors during shutdown sequence in
some vendor's platform, and it is required to disable error handling
during shutdown.
This CL separates the shutdown request to execute another "shutdown"
trigger at the beginning of shutdown stage. And vendor can use this
trigger to add custom commands needed for shutting down gracefully.
Bug: 38203024
Bug: 62084631
Test: device reboot/shutdown
Change-Id: I3fac4ed59f06667d86e477ee55ed391cf113717f
It's not a error case if we do not find a device that we're attempting
to regenerate uevents for during first stage mount, but it is likely
to increase boot time, so we log a message to attribute this delay.
Bug: 63327193
Test: Boot bullhead, sailfish
Change-Id: I97c2e5aefd218bbdd87717ff3c375381f725de08
When Android is running in a container, some of the securebits might be
locked, which makes prctl(PR_SET_SECUREBITS) fail.
This change gets the previous state of the process' securebits and adds
the desired bits.
Bug: 62388055
Test: aosp_bullhead-eng boots
Test: If init has non-zero securebits, it can also boot
Change-Id: Ie03bf2538f9dca40955bc58314d269246f5731bd
When init gets SIGCHLD, it uses waitpid() to get the pid of an exited
process. It then calls kill(-pid, ...) to ensure that all processes
in the process group started by that process are killed as well.
There is a bug here however as waitpid() reaps the pid when it
returns, meaning that the call to kill(-pid, ...) may fail with ESRCH
as there are no remaining references to that pid. Or worse, if the
pid is reused, the wrong processes may get the signal.
This fixes the bug by using waitid() with WNOWAIT to get the pid of an
exited process, which does not reap the pid. It then uses waitpid()
with the returned pid to do the reap only after the above kill(-pid,
...) and other operations have completed.
Bug: 38164998
Test: kill surfaceflinger and see that processes exit and are reaped
appropriately
Test: `adb reboot` and observe that the extraneous kill() failed
messages do not appear
Change-Id: Ic0213e1c97e0141e6c13129dc2abbfed86de138b
This change homogenizes the use of std::unique_ptr for storing
capabilities in system/core/.
Bug: None
Test: m
Change-Id: I0a95f87a27b0261e9d321841d5140fc000473293
This change makes it possible for Android running in a container to
terminate cleanly instead of calling abort() when requested to shut
down.
Bug: 62388055
Test: `adb reboot` on bullhead causes no kernel panics
Test: `adb reboot` on a system without CAP_SYS_BOOT makes init terminate
nicely
Change-Id: I36b2298610f5b4a2bf8b05103d04804883df2c88
This change makes it possible for Android running in a container to
terminate cleanly instead of calling abort() when requested to shut
down.
Bug: 62388055
Test: setprop sys.powerctl reboot makes init terminate nicely
Change-Id: I31c7b475d89d7cbd665e135d9b8951dfd4bca80d
While refactoring ueventd, I was looking for code the character device
symlinks (/dev/usb/*) that ueventd creates, such that I could test it
on a real device. I found none in our tree, and history showing Xoom,
which was last supported years ago, was the last user. If this code
is in fact obsolete, let's remove it.
Test: boot bullhead
Test: init unit tests
Change-Id: I601f7165eb06d36b31b6dcf69ee9e0a449d81a96
The generic system.img released from project Treble can't contain any verity
metadata (e.g., vboot 1.0, AVB, or any other implementation) because it's
*generic*. To make any device can boot with it, `avbctl disable-verification`
is introduced to set a new flag AVB_VBMETA_IMAGE_FLAGS_VERIFICATION_DISABLED
in the top-level vbmeta to disable the entire AVB verification process. This
should be done prior to flash the generic system.img. See the following link
for details:
https://android-review.googlesource.com/#/c/418399/
This CL checks whether AVB_VBMETA_IMAGE_FLAGS_VERIFICATION_DISABLED is
set in the top-level vbmeta. When set, skip verifying the vbmeta structs
against androidboot.vbmeta.{hash_alg, size, digest} because it will be
absent in kernel cmdline. Also, only top-level vbmeta struct is read then
returned by libavb in this case.
Note that another flag AVB_VBMETA_IMAGE_FLAGS_HASHTREE_DISABLED, usually
set by `adb disable-verity`, is used to signal fs_mgr to skip setting up
dm-verity, but libavb still verifies all vbmeta structs. fs_mgr will
also verify all vbmeta structs against androidboot.vbmeta.{hash_alg,
size, digest} from kernel cmdline as well.
Also rename SetUpAvb() to SetUpAvbHashtree() to better fit its usage.
This function will return kDisabled when any of the above two flags is set.
Finally, regardless of which flag is set or not set, we still only allow two
return values from avb_slot_verify():
- AVB_SLOT_VERIFY_RESULT_OK: it's still possible to get this value
when any of these flags are set in build time. e.g.,
BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS=--flags 2
- AVB_SLOT_VERIFY_RESULT_ERROR_VERIFICATION: in most cases we should
get this value, because the flags are likely set at run time.
Bug: 62523303
Test: boot device with 'avbctl disable-verification'.
Test: boot device with 'avbctl enable-verification'.
Test: boot device with 'adb disable-verity'.
Test: boot device with 'adb enable-verity'.
Test: build image with BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS=--flags 2, then boot device.
repeat the above steps to boot device again.
Change-Id: Ie8436f3e0e82c78490208f3b85eac5238a9fdfdb
1) property_set() takes const std::string& for both of its arguments,
so stop using .c_str() with its parameters
2) Simplify a few places where StringPrintf() is used to concatenate strings
3) Use std::to_string() instead of StringPrintf() where it's better suited
Test: Boot bullhead
Test: init unit tests
Change-Id: I68ebda0e469f6230c8f9ad3c8d5f9444e0c4fdfd
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>
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
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
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
Current first stage mount only allows three mount points: system, vendor
and/or odm. This was introduced by project Treble to mount those
verified partitions early. However, there might be some other custom
partitions needs to be mounted early as well. This CL removes the
restriction and does first stage mount for whatever specified in
fstab-dt.
Bug: 62423887
Test: first stage mount /vendor with vboot 1.0
Test: first stage mount /vendor with vboot 2.0 (AVB)
Change-Id: I6c146c64e673c35c2823523ccbde193590430c48
libprocessgroup kills the cgroup associated with a given pid and uid,
but not the POSIX process group associated with it. This means that
to kill both, two of the same signals must be sent, which may cause
some issues.
This change kills all POSIX process groups whose group leaders are
found within a cgroup. It only then kills processes in the cgroup
that are not part of the POSIX process groups that have been killed.
Bug: 37853905
Bug: 62418791
Test: Boot, kill zygote, reboot
Change-Id: Id1d96935745899b4c454c36c351ec16a0b1d3827
fork() subprocesses to handle uevents in parallel.
This reduces coldboot time on bullhead from ~446ms to ~230ms.
This reduces coldboot time on sailfish from ~690ms to ~360ms.
This reduces coldboot time on ryu from ~187ms to ~122ms.
Bug: 33785894
Test: boot bullhead x40, observe no major differences in /dev and /sys
Test: boot sailfish x40, observe no major differences in /dev and /sys
Test: boot ryu x40, observe no major differences in /dev and /sys
Test: boottime tests on bullhead and sailfish
Test: init unit tests
Change-Id: Ie2f63e000b8af78d187477d31fe109f20304d749
Bug: 62114389
Test: boot bullhead, get/set properties with ':' via command line
Test: trigger an init trigger with a property containing a ':'
Change-Id: Ib51853a1ef9d4f79d510c8175c0d9684e2025e23
devices.cpp handles too many things for creating one class. This
change breaks it up into various files and classes.
* Parsing is moved to ueventd_parser.cpp
* Reading from the uevent socket and Cold booting is moved to a
UeventListener class, in uevent_listener.cpp
* Firmware handling is moved to firmware_handler.cpp
* The remaining contents form a DeviceHandler class within devices.cpp
Bug: 33785894
Test: boot bullhead x40, observe no major differences in /dev and /sys
Test: boot sailfish x40, observe no major differences in /dev and /sys
Test: init unit tests
Change-Id: I846a2e5995fbb344c7a8e349065c18a934fa6aba
Move libinit, init_tests, and test_service to Android.bp
Leave init in Android.mk as it has unfulfilled dependencies, but
create a comment in Android.bp for future use.
Remove libinit_parser and init_parser_tests as that code was never
used in init.
Bug: 36970783
Bug: 37512442
Test: Build, boot bullhead, init unit tests
Change-Id: Id81cd10ea09453a5fd762ba9189276aad79d5444
- In some devices, some drivers still try to load firmware while shutting
down, and crashes the kernel. So keep ueventd to prevent such case.
bug: 38203024
Test: reboots
Change-Id: I4f1910723254ccb69f8e9c78e8727fbd8c7eed3e
* changes:
init: change kill order and fix error reporting in KillProcessGroup()
Better logging in libprocessgroup and make resources clean up themselves
Treehugger Robot