Setting memory.soft_limit_in_bytes on high-end devices with large memory
reserves affects performance of memory-hungry applications that have
large workingsets and keep thrashing because of the memory limits imposed.
Limit the usage of memory.soft_limit_in_bytes to low-memory devices only.
Add debug messages for future troubleshooting to capture cases when
vmpressure events are being ignored.
Bug: 78916015
Test: collect vmstat while running a heavy app
Change-Id: Ib4434b96d2be802ef89960b573486eae8d12f198
Merged-In: Ib4434b96d2be802ef89960b573486eae8d12f198
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
The new lld linker uses all non-zero offset executable maps. There was
a bug when trying to find if the stack is in a signal handler that caused
the code to read the wrong place in the elf. Fixed by not adding the elf
offset to the relative pc.
Also fixed the unwind_for_offline tool to dump multiple stacks if necessary.
Added new offline unit test that would have failed with the old code.
Bug: 79936827
Test: Ran unit tests and libbacktrace unit tests.
Test: Dumped backtraces of system pids.
Test: Ran 137-cfi art test.
Change-Id: Iaca8c18c2a314902e64c3f72831234297e8dcb1b
Merged-In: Iaca8c18c2a314902e64c3f72831234297e8dcb1b
(cherry picked from commit 239425b9fa)
downloaded apns-conf.xml will be stored in the folder
/data/misc/apns/ to make sure TelephonyProvider gets
access.
Bug: 79948106
Test: Manual
Change-Id: I4ba0596fa6523c0eb96328dbe46ead02587bd9b8
Add the ability to enter a network namespace when launching a service.
Typical usage of this would be something similar to the below:
on fs
exec ip netns add namespace_name
service vendor_something /vendor/...
capabilities <lower than root>
user not_root
enter_namespace net /mnt/.../namespace_name
Note changes to the `ip` tool are needed to create the namespace in
the correct directory.
Bug: 73334854
Test: auto team verified
Merged-In: Ifa91c873d36d69db399bb9c04ff2362518a0b07d
Change-Id: Ifa91c873d36d69db399bb9c04ff2362518a0b07d
(cherry picked from commit aead51b418)
During uevent processing, some "by-name" symlinks will be created.
/dev/block/<type>/<device>/by-name/<partition>
<type> can be: platform, pci or vbd.
<device> might be: soc.0/f9824900.sdhci, soc.0/f9824900.sdhci, etc.
<partition> might be: system, vendor, system_a, system_b, etc.
e.g., on a non-A/B device:
/dev/block/platform/soc.0/f9824900.sdhci/by-name/system
/dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor
On a A/B device:
/dev/block/platform/soc/1da4000.ufshc/by-name/system_a
/dev/block/platform/soc/1da4000.ufshc/by-name/system_b
/dev/block/platform/soc/1da4000.ufshc/by-name/vendor_a
/dev/block/platform/soc/1da4000.ufshc/by-name/vendor_b
However, those symlinks are "device-specific".
This change adds the "generic" symlinks in ueventd, in addition to
the existing symlinks, when the possible "boot devices" are specified
in device tree. e.g.,
&firmware_android {
compatible = "android,firmware";
boot_devices ="soc/1da4000.ufshc,soc.0/f9824900.sdhci";
}
The following symlinks will then be created on the aforementioned non-A/B
and A/B devices, respectively.
/dev/block/by-name/system
/dev/block/by-name/vendor
/dev/block/by-name/system_a
/dev/block/by-name/system_b
/dev/block/by-name/vendor_a
/dev/block/by-name/vendor_b
Note that both <type> and <device> are skipped in the newly create symlinks.
It assumes there is no more than one devices with the same <partition>,
which is the assumption of current first stage mount flow.
Finally, when 'boot_devices' in DT is absent, it fallbacks to extract
'boot_devices' from fstab settings. e.g., using 'soc/1da4000.ufshc',
'soc.0/f9824900.sdhci' for a fstab with the following content:
/dev/block/platform/soc/1da4000.ufshc/by-name/system
/dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor
Bug: 78613232
Test: adb shell ls /dev/block/by-name
Change-Id: Iec920b5a72409b6a2bdbeeb290f0a3acd2046b5d
Merged-In: Iec920b5a72409b6a2bdbeeb290f0a3acd2046b5d
(cherry picked from commit 8eec38f4e4)
The uevent.partition_num easily collides between partitions, for
example:
Both /dev/block/sda3 and /dev/block/sdd3 will generate the same symlink:
/dev/block/platform/soc/1da4000.ufshc/by-num/p3
This change remove those by-num symlinks as there seems no effective
user of it.
Bug: 78613232
Test: m init_tests && \
adb push $OUT/data/nativetest64/init_tests/init_tests /data/. && \
adb shell /data/init_tests
Change-Id: I8dfa8dc1a2f9fc9296aa30f33e905bf158b501de
Merged-In: I8dfa8dc1a2f9fc9296aa30f33e905bf158b501de
(cherry picked from commit 95591bd00e)
Add the ability to enter a network namespace when launching a service.
Typical usage of this would be something similar to the below:
on fs
exec ip netns add namespace_name
service vendor_something /vendor/...
capabilities <lower than root>
user not_root
enter_namespace net /mnt/.../namespace_name
Note changes to the `ip` tool are needed to create the namespace in
the correct directory.
Bug: 73334854
Test: not yet
Change-Id: Ifa91c873d36d69db399bb9c04ff2362518a0b07d
During uevent processing, some "by-name" symlinks will be created.
/dev/block/<type>/<device>/by-name/<partition>
<type> can be: platform, pci or vbd.
<device> might be: soc.0/f9824900.sdhci, soc.0/f9824900.sdhci, etc.
<partition> might be: system, vendor, system_a, system_b, etc.
e.g., on a non-A/B device:
/dev/block/platform/soc.0/f9824900.sdhci/by-name/system
/dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor
On a A/B device:
/dev/block/platform/soc/1da4000.ufshc/by-name/system_a
/dev/block/platform/soc/1da4000.ufshc/by-name/system_b
/dev/block/platform/soc/1da4000.ufshc/by-name/vendor_a
/dev/block/platform/soc/1da4000.ufshc/by-name/vendor_b
However, those symlinks are "device-specific".
This change adds the "generic" symlinks in ueventd, in addition to
the existing symlinks, when the possible "boot devices" are specified
in device tree. e.g.,
&firmware_android {
compatible = "android,firmware";
boot_devices ="soc/1da4000.ufshc,soc.0/f9824900.sdhci";
}
The following symlinks will then be created on the aforementioned non-A/B
and A/B devices, respectively.
/dev/block/by-name/system
/dev/block/by-name/vendor
/dev/block/by-name/system_a
/dev/block/by-name/system_b
/dev/block/by-name/vendor_a
/dev/block/by-name/vendor_b
Note that both <type> and <device> are skipped in the newly create symlinks.
It assumes there is no more than one devices with the same <partition>,
which is the assumption of current first stage mount flow.
Finally, when 'boot_devices' in DT is absent, it fallbacks to extract
'boot_devices' from fstab settings. e.g., using 'soc/1da4000.ufshc',
'soc.0/f9824900.sdhci' for a fstab with the following content:
/dev/block/platform/soc/1da4000.ufshc/by-name/system
/dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor
Bug: 78613232
Test: adb shell ls /dev/block/by-name
Change-Id: Iec920b5a72409b6a2bdbeeb290f0a3acd2046b5d
Tom Cherry