In ART, some of the maps are /memfd:/jit-cache and it triggers the warning
about unreadable elf files. Do not set the elf from memory not file
flag in this case.
Bug: 131909548
Test: New unit tests pass.
Test: No warnings dumping stacks with this change done.
Change-Id: Ifba5e65da609525ded75430da173c614f6e4801e
(cherry picked from commit 98aaf4cf08)
A previous patch intended to make receiving multiple FUNCTIONFS_ENABLEs
non-fatal, but failed to do so because we would try to spawn another
worker thread and hit a different assertion.
Bug: http://b/130638368
Test: echo mem | adb shell "su 0 sh -c 'cat > /sys/power/state'"
Change-Id: I53456112244d8b4f7d26df6ec6961389fca70498
(cherry picked from commit 910ce0ff08)
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
Merged-In: Iffa7c5f24d8f409e71f89fe9ece274d8c476f6fc
If the matching string contains a [, \ or *, then it is also checked
with a regex match. Exact match is always tried firsts. If we do
not find an exact string match, switch to iterate through the entire
list for regex strings to find a match.
This allows us to scale with details without consuming a large
number of enums, permitting details that we do not necessarily want
resolution on to propagate to TRON. The hierarchical nature of the
boot reason <reason>,<subreason>,<detail>... can cause scenarios
where the <detail> does not matter to TRON, but does matter to
bugreport collection.
Add a bootstat --boot_reason_enum function to expose and test the
kBootReasonMap matchihg algorithm.
Add a kBootReasonMap test that exhaustively tests all built-in
entries, and an example of one regex entry. New regex entries added
to bootstat.cpp will need a series of exact match examples added into
filter_kBootReasonMap() function.
Test: boot_reason_test.sh kBootReasonMap (or all tests)
Bug: 116838876
Bug: 128929506
Change-Id: I3f7b5de22f99195b7ce99672a212174365960b3f
Merged-In: I3f7b5de22f99195b7ce99672a212174365960b3f
After this change, all the noise from mkfs is suppressed:
$ adb remount
[libfs_mgr]superblock s_max_mnt_count:65535,/dev/block/by-name/system_b
[libfs_mgr]__mount(source=/dev/block/by-name/system_b,target=/mnt/scratch,type=ext4)=-1: Invalid argument
[libfs_mgr]__mount(source=/dev/block/by-name/system_b,target=/mnt/scratch,type=f2fs)=0: Success
Using overlayfs for /system
Using overlayfs for /vendor
Using overlayfs for /product
[libfs_mgr]__mount(source=overlay,target=/system,type=overlay,upperdir=/mnt/scratch/overlay/system/upper)=0
[libfs_mgr]__mount(source=overlay,target=/vendor,type=overlay,upperdir=/mnt/scratch/overlay/vendor/upper)=0
[libfs_mgr]__mount(source=overlay,target=/product,type=overlay,upperdir=/mnt/scratch/overlay/product/upper)=0
remount succeeded
Test: manual as above
Bug: 130739326
Change-Id: I7ed8842e42b74b6a487ce6324b28baf78f1f63bf
Merged-In: I7ed8842e42b74b6a487ce6324b28baf78f1f63bf
Before, if updatable processes crash 4 times in 4mins, a native
rollback will be attempted. This behavior does not detect
system_server early boot deadlocks because the system server requires
at least a min to detect a deadlock, and crash itself. The crashes
don't happen frequently enough for init to detect.
After, this cl, the old behavior exists and additionally, init detects
*any* 4 crashes of updatable processes before boot completed,
regardless of if they happen within 4mins or not.
Test: Manually tested by adding artificial sleep in system_server so
deadlock is triggered before boot. system_server crashes 4 times in
over 4mins and the ro.init.updatable_crashing prop is set to 1.
Bug: 129597207
Merged-In: Ie6fb5693ff4be105bcbe139c22850fb076e40260
Change-Id: Ie6fb5693ff4be105bcbe139c22850fb076e40260
Support `adb rescue wipe` command on the host side. This command runs
under the rescue mode and wipes data (and cache/metadata).
Bug: 131037235
Test: run adb rescue wipe
Change-Id: Ib3a3f2d564cc19d0446540d616cc21489ba558c2
(cherry picked from commit c2265c5343)
Create the anonymous namespace only from a non-empty library path.
This is a better heuristic than the current "first-come" one. It
allows creating classloaders that are not directly related to an
app's "main" classloader, that is, do not have any library path.
This is the case, for example, for shared libraries, including
preloaded ones.
Longer-term, the anonymous namespace creation should be made
explicit, so that the framework can have full control.
(cherry picked from commit b9df7d936c)
Bug: 130623656
Test: m
Test: manual
Merged-In: I8251363b372e365d10ae09d23df93d76388ac7f9
Change-Id: I8251363b372e365d10ae09d23df93d76388ac7f9
This is for Android Telemetry to be able to categorise the processes
that produce tombstones.
Bug: 129933535
Test: atest debugerd_test:TombstoneTest
Change-Id: Ie635347c9839eb58bfd27739050bd68cbdbf98da
Merged-In: Ie635347c9839eb58bfd27739050bd68cbdbf98da
(cherry picked from commit e5b7913d2c5da92c37233fef15ab3109e37d9c90)
procrank's usage in its output shows 20x increase from
last year. This is because it is keeping the process
maps around until termination. Fix that by getting rid
of ProcMemInfo objects when done parsing /proc/<pid>/maps,pagemap.
Note that the total allocations do not change and have not necessarily
regressed from Pie.
Bug: 130672819
Test: adb shell procrank | grep 'procrank\|cmdline'
Change-Id: Ib7bf960ed1d053347fcfc0c8aee9019607a1eb01
Merged-In: Ib7bf960ed1d053347fcfc0c8aee9019607a1eb01
Signed-off-by: Sandeep Patil <sspatil@google.com>
This CL adds client support to recognize the rescue mode (which will be
served by recovery image). It also allows waiting for a device to enter
rescue mode. The support for the actual rescue commands will be added in
follow-up CLs.
Bug: 128415917
Test: `adb devices` recognizes devices under rescue mode.
Test: `adb wait-for-rescue` waits for device to be in rescue mode.
Change-Id: I367d7339fe68006aba09a1e3db6370d472296676
Merged-In: I367d7339fe68006aba09a1e3db6370d472296676
(cherry picked from commit 55d407ec4a)
On devices that use FDE and APEX at the same time, we need to bring up a
minimal framework to be able to mount the /data partition. During this
period, a tmpfs /data filesystem is created, which doesn't contain any
of the updated APEXEs. As a consequence, all those processes will be
using the APEXes from the /system partition.
This is obviously not desired, as APEXes in /system may be old and/or
contain security issues. Additionally, it would create a difference
between FBE and FDE devices at runtime.
Ideally, we restart all processes that have started after we created the
tmpfs /data. We can't (re)start based on class names alone, because some
classes (eg 'hal') contain services that are required to start apexd
itself and that shouldn't be killed (eg the graphics HAL).
To address this, keep track of which processes are started after /data
is mounted, with a new 'mark_post_data' keyword. Additionally, create
'class_reset_post_data', which resets all services in the class that
were created after the initial /data mount, and 'class_start_post_data',
which starts all services in the class that were started after /data was
mounted.
On a device with FBE, these keywords wouldn't be used; on a device with
FDE, we'd use them to bring down the right processes after the user has
entered the correct secret, and restart them.
Bug: 118485723
Test: manually verified process list
Change-Id: I16adb776dacf1dd1feeaff9e60639b99899905eb
Each operation we submit results in a contiguous allocation in the
kernel which can trigger OOM-killing. Tune the queue depths to reduce
the chances of this happening, with a minimal impact on performance.
Bug: http://b/126582877
Test: ./benchmark_device.py with blueline
Change-Id: I4b0f83d54a9a9a69f0ab48322d78fb137c94dd35
(cherry picked from commit 28293f16a8)
The first stage init skips mounting the mount points defined in
skip_mount.cfg, but these mount points still return from
ReadDefaultFstab(). The behavior causes some error logic which
try to access the partition which had been skipped.
After applying the patch. ReadDefaultFstab() will not contain the
skipped mount points.
Bug: 128961335
Test: `fastboot delete-logical-partition product_a`
Test: `fastboot flash system aosp_arm64-userdebug`
Test: `fastboot -w reboot` and boot to home screen
Change-Id: I3156260b5d37647dbecf98ca90601a089bea5c46
Merged-In: I3156260b5d37647dbecf98ca90601a089bea5c46
(cherry picked from commit 77c28476f1)
The debug ramdisk can only be used if the device is unlocked.
When it's used, init will load adb_debug.prop and the userdebug
sepolicy from the debug ramdisk, to allow adb root on a user build.
Bug: 126493225
Test: 'make' and checks the file is installed
Change-Id: Id6962414197fc8f47f7c07818e8fb16107dc17a3
Merged-In: Id6962414197fc8f47f7c07818e8fb16107dc17a3
(cherry picked from commit 05f07d89a6)
Limit libprocessgroup VNDK API to the minimum set required for task
profiles usage. This API allows vendors to use cgroups without accessing
cgroup files directly, therefore allowing Android to change cgroup
arrangement details without breaking vendor code.
Bug: 131098932
Test: build and boot
Change-Id: I92463dfb44a108a133bafd2fe52237b6b1d50a69
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
This reverts commit bee9f5718b
"libprocessgroup: Disable file descriptor caching temporarily" and adds
option to use SetTaskProfiles and SetProcessProfiles without file caching.
This option is used from JNI to avoid access denials because cached files
are not whitelisted for JNI usage.
Bug: 123868658
Bug: 123043091
Test: boot using svelte target
Change-Id: I76b9d6af8a1dd4464cb3cf3e6dc327980efdf361
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
In previous implementation, userdebug sepoilcy and property files are
loaded from the system.img. This CL changes this to:
- first-stage init copies userdebug files from ramdisk to /debug_ramisk/*
- second-stage init loads files from /debug_ramdisk/*.
Note: same as before, the above can only be triggered, if the device
is UNLOCKED
With this, we don't have to put userdebug related files into the USER
system.img.
Bug: 126493225
Test: boot device with a ramdisk with /force_debuggable, checks related
files are loaded
Change-Id: I63f5f846e82ba78427062bf7615c26173878d8f3
Merged-In: I63f5f846e82ba78427062bf7615c26173878d8f3
(cherry picked from commit 30afda71c0)
Modify the unwinder library to indicate that at least one of the stack
frames contains an elf file that is unreadable.
Modify debuggerd to display a note about the unreadable frame and a possible
way to fix it.
Bug: 129769339
Test: New unit tests pass.
Test: Ran an app that crashes and has an unreadable file and verified the
Test: message is displayed. Then setenforce 0 and verify the message is
Test: not displayed.
Change-Id: Ibc4fe1d117e9b5840290454e90914ddc698d3cc2
Merged-In: Ibc4fe1d117e9b5840290454e90914ddc698d3cc2
(cherry picked from commit 4ae266ccbd)
right now vendor_init is forked before we set oom_adj for init which
leaves a chance vendor_init could be killed in heavy memory pressure.
this CL set the oom_adj before forking everything to ensure all native
have correct oom_adj settings.
Fixes: 130824864
Test: procrank -o
(cherry picked from commit 45d8174fe7)
Change-Id: I68c18f9db24d55239f7f0608592fcc702f04542e
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
(cherry picked from commit 18cb681247)
Some USB controllers only support 16k writes, so drop down to that.
Bug: http://b/130622010
Test: treehugger
Change-Id: I836d5b2d0d6fcae05f290af11a6a19c6e8d7c1ba
(cherry picked from commit 770a6a4d46)
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
Merged-In: I9a140c7d9d93e1dd43c34c8cf066f4a62e2bf604
Christopher Ferris