Some app may have different cgroup settings in cpuset and schedtune for its
threads, so let blkio follow cpuset only, which represents the app's current
state more accurately. Otherwise, if that thread is doing IO, then its
performance will be affected because its blkio group is in lower priority
group as schedtune.
ex: an app is now in top-app, but some thread of it set schedtune group to
background, and blkio follows schedtune because it is called later.
Main thread:
6:schedtune:/top-app
5:memory:/
4:cpuset:/top-app
3:cpuacct:/uid_1000/pid_8766
2:cpu:/
1:blkio:/
0::/
Some thread:
6:schedtune:/background
5:memory:/
4:cpuset:/top-app
3:cpuacct:/uid_1000/pid_8766
2:cpu:/
1:blkio:/background
0::/
Bug: 124727032
Test: blkio has same settings with cpuset
Change-Id: I9a140c7d9d93e1dd43c34c8cf066f4a62e2bf604
There appears to be a kernel bug that causes SIGHUP and SIGCONT to be
sent to the parent process group we spawn from if the process group
contains stopped jobs (e.g. the parent itself, because of wait_for_gdb).
Call setsid in all of our children to prevent this from happening.
Bug: http://b/31124563
Test: adb shell 'setprop debug.debuggerd.wait_for_gdb 1; killall -ABRT surfaceflinger'
Change-Id: I1a48d70886880a5bfbe2deb80d48deece55faf09
umount_all is the cleanup step for mount_all.
In particular, the mount_all builtin creates a verity device,
'postinstall-verity', for the following line:
system /postinstall ... ... slotselect_other,logical,avb_keys=...
cppreopt umounts /postinstall but doesn't destroy the postinstall-verity
device, causing OTA to fail (because it cannot destroy the
system_[other] device). umount_all also destroy the verity device.
Note that mount_all does not map system_[other]; it is mapped by
first stage init. Hence, umount_all doesn't destroy it either. The OTA
client is reponsible for unmapping the device itself.
Bug: 129988285
Test: flash, boot, then check `dmctl list devices`, then OTA
Change-Id: Id3ab65b3860b6ea6cfec310ab13652009c81f415
Merged-In: Id3ab65b3860b6ea6cfec310ab13652009c81f415
Currently if the device is unplugged from host,
there is a lot of log spamming since fastbootd
does not not recognize that the device has been
disconnected and keeps trying to read/write to the
device.
2856 printk messages dropped ** [ 169.941904] c7 579 fastbootd: aio: got error event on
read total bufs 1: No such devie
** 2960 printk messages dropped ** [ 169.953328] c7 579 fastbootd: Fastboot command:
** 2074 printk messages dropped ** [ 169.961355] c7 579 fastbootd: aio: got error event
on read total bufs 1: No such devie
Bug: 121333158
Test: unplug device and check for log spam multiple times
Change-Id: I1d4c6f48f34e313c5ebce23d62a4fe6a6373f94f
This refactors the step function slightly to split it up into
distinct pieces since the code needs to handle a signal handler
versus normal step slightly differently.
Add a new error for an invalid elf.
Modify libbacktrace code to handle new error code.
Bug: 130302288
Test: libbacktrace/libunwindstack unit tests.
Change-Id: I3fb9b00c02d2cf2cc5911541bba0346c6f39b8e6
For bringup devices that do not have right-sized partition, and if
/system is now root, check / to be sure.
Consider unshare blocks for ext4 as dead code, provide a strong
message to caller to provide all the dependencies to overlayfs.
Test: adb-remount-test.sh
Bug: 130327601
Change-Id: Iffa7c5f24d8f409e71f89fe9ece274d8c476f6fc
On some devices (e.g., emulator), init needs to read AVB footer from
a logical partition because:
1) Dynamic/logical partition is enabled
2) The partition is AVB chained, i.e., need to locate footer from the end
3) Logical partition is not understandable by bootloader,
but there is no bootloader in this case
Bug: 125540538
Bug: 128434470
Test: boot and force the fallback path, to check it can get logical path
Change-Id: Ie304bce234cbf0f938f386f7ce59235c851e0e2d
Children of processes that use SocketListener should not be able
to stop the SocketListener.
Test: builds, boots
Test: atest libsysutils_tests
Test: atest --test-mapping system/netd
Change-Id: I64898d9966f62004468b8e8a43b59be4a81a8cc4
charger needs to suspend the device when the power goes away
when it doesn't have root. These two files are marked with
group system, user system, mode 0600 in 'on boot', but
it is not executed in charger. Hence, move these actions
to 'on init'.
Test: no failure in libsuspend in charger
Bug: 129138950
Change-Id: I787b935b4ff6177601329aeedccdac361b119ca3
Merged-In: I787b935b4ff6177601329aeedccdac361b119ca3
In an effort to ensure that our development community does not
introduce new code without corresponding SELinux changes, Android
closely monitors the number of SELinux denials which occur during
boot. This monitoring occurs both in treehugger, as well as various
dashboards. If SELinux denials are dropped during early boot, this
could result in non-determinism for the various SELinux treehugger
tests.
Introduce /system/bin/auditctl. This tool, model after
https://linux.die.net/man/8/auditctl , allows for configuring the
throttling rate for the kernel auditing system.
Remove any throttling from early boot. This will hopefully reduce
treehugger flakiness by making denial generation more predictible
during early boot.
Reapply the throttling at boot complete, to avoid denial of service
attacks against the auditing subsystem.
Delete pre-existing unittests for logd / SELinux integration. It's
intended that all throttling decisions be made in the kernel, and
shouldn't be a concern of logd.
Bug: 118815957
Test: Perform an operation which generates lots of SELinux denials,
and count how many occur before and after the time period.
Change-Id: I6c787dbdd4a28208dc854b543e1727ae92e5eeed
procrank currently fails if a process gets killed while it is reading
the stats. This behavior is a regression from the previous version of
procrank and is often undesired.
Change procrank to silently ignore the process if it detects that it had
been killed while reading the stats. If the process is still around,
then print a warning about it and continue to read stats for other
processes in the system.
Bug: 130177765
Test: Tested by deliberately killing specific process in ProcessRecord()
constructor
Change-Id: I701808c3226bb9b3a350ccf8e67fb29b59b0d4e0
Signed-off-by: Sandeep Patil <sspatil@google.com>
This change allows specifying additional avb keys to verify a fstab
entry. It can be used together with the original 'avb' flag. When both
'avb' and 'avb_keys' are present, it will try to use avb_keys to verify
this partition and extract the AVB descriptor from the end of it first.
When avb_key fails, it falls back to searching the AVB descriptor in the
built-in /vbmeta (and its chained partitions) with the matched partition
name.
An example of a fstab file:
system /system ext4 ro,barrier=1 wait,slotselect,avb=vbmeta,logical,first_stage_mount,avb_keys=/avb/gsi.avbpubkey
vendor /vendor ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount
The overhead of adding an additional 'avb_keys' should not be significant,
as the typical size of a AVB Hashtree descriptor for /system is usually
less than 1000 bytes. e.g., on crosshatch, it's about 600 bytes, which
takes less than 1 millisecond for the following call to return failure.
auto avb_standalone_handle = AvbHandle::LoadAndVerifyVbmeta(*fstab_entry);
We also checked the time spent on init's first stage on crosshatch, with the
following CL to set ro.boottime.init.first_stage. The testing result
shows no significant difference between them as well.
https://android-review.googlesource.com/c/platform/system/core/+/934536
With an additional avb_keys entry for /system
[ro.boottime.init.first_stage]: [728]
[ro.boottime.init.first_stage]: [720]
[ro.boottime.init.first_stage]: [722]
Without an additional avb_keys entry for /system
[ro.boottime.init.first_stage]: [730]
[ro.boottime.init.first_stage]: [728]
[ro.boottime.init.first_stage]: [725]
Bug: 124491153
Test: boot a device with above fstab settings
Change-Id: I0c81f816efb0dd40c93da2df304f2e215df9d105
Dongwon Kang