We recently created a new GID that can be granted to critical system
processes, so that the system is usable enough for the user to free
up disk space used by abusive apps.
Test: builds, boots
Bug: 62024591
Change-Id: Ia5af7535cc05a214f8720ac08c594c6db888597a
If we're setting up the number of reserved blocks, we also want to
set our new AID_DISK_RESERVED as the GID that's allowed to use those
blocks.
Test: builds, boots
Bug: 62024591
Change-Id: Iaabfa7d63ad9ff0b9732e2b9996937607d622fe2
Filesystems allow the setting of the "resgid" parameter to designate
a GID that is allowed to use the "reserved" disk space (in addition
to UID 0). We'll be granting this GID to critical system processes,
so that the system is usable enough for the user to free up disk
space used by abusive apps.
Test: builds, boots
Bug: 62024591
Change-Id: I2d166f3b730f0a3e7279fb40f12db7413c1dadad
This doesn't seem to work. All other projects restrict sanitization,
too.
Mac build not actually tested.
Test: m
Test: linux host build still contains ubsan symbols
Change-Id: I60532a46177632320ba3b15b4a7c2d5e31ef2bfc
The fstab struct wasn't properly being freed.
Test: Ensure a user of fs_mgr (vold) runs without errors.
Change-Id: I4dcb8ae2ab3e831fbdb13372eb31a67a5d9fb735
The odm partition will eventually be required. Prepare for this by
creating its mount point.
Bug: 37322799
Test: run cts-dev -m CtsPermissionTestCases
Change-Id: Ibd031b68dd7328c853ded401bb2690dbd6675141
There is a 2s timeout for system property set that currently
uses boot_clock as its clock source. If the system goes to sleep
during a property set, it may erroneously cause the timeout to
be reached as boot_clock increments during sleep. This patch
changes from boot_clock to steady_clock to ignore time spent
asleep when determining this timeout.
bug: 71497234
Test: 1. System service process try to set a system property
with timeout 2s
2. At the same time, the system go into sleep mode more
than 2s
3. System property set will be ok.
Change-Id: I808b9af16974a0f4de60a4ca30ae64d095a13422
Select a low rate-limit to cut down on logspam and resulting
performance regressions.
Functionally reverts 247d682fe1
(logd: sepolicy dynamic rate limiting) and sets a static low
rate-limit. Before 247d682f, the limit was statically set to 20.
247d682f continued to support 20, but if sustained dropped the limit
to 5. This revert leaves us at 5 so as not to impact performance.
Test: /data/nativetest/logd-unit-tests/logd-unit-tests \
--gtest_filter=logd.sepolicy_rate_limiter
[ PASSED ] 1 test.
Bug: 71538411
Change-Id: I6c92f4ba825cc24beb8f1f1b79258fa8097c837b
We pin lmkd in memory so that we don't take page faults (and thus
requisition memory) while we're in the process of responding to a
low-memory condition. mlockall(2) is the right primitive for this
pinning. Previously, we used the MCL_FUTURE flag to mlockall: used
this way, mlockall doesn't actually pin all pages in memory, since
MCL_FUTURE affects only the default flags for future mappings and
doesn't affect mapping already in existence at the time of the
mlockall call --- like the lmkd executable itself.
This patch adds the MCL_CURRENT flag, which also pins all pages
already mapped.
Test: code inspection
Change-Id: I4563959367a2f0a9cadc3ea41731b7f311326685
Attempt to (somewhat) support the given library path on a non-Android
device. Iterate through the given list and construct a complete path.
This will of course not handle dependencies correctly and is best
effort.
Required (and enough) for agent-related testing in ART.
Bug: 70901841
Test: m
Change-Id: I9ecb27d662c8a2c79a70b6c5464483c449c5d034
Jeff Sharkey