Add a simple SIGCHLD handler to reap zombie processes given to init.
Bug: 197662257
Change-Id: I6e7930cfd7c311c454b361b9a541369ece2eb744
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
* changes:
Reduce the queue depth of loop devices used by the zram driver
libdm: Export ExtractBlockDeviceName()
libdm: Make ExtractBlockDeviceName() return its result
Make the queue depth of loop devices identical to that of the underlying
storage device. This patch reduces latency by lowering the queue depth.
With this patch applied I see the following:
# cat /sys/block/loop30/queue/nr_requests
32
Bug: 194450129
Test: Built Android images, installed these and verified that the queue depth of loop devices is 32 instead of 256.
Change-Id: Ifa16084c7df3a54d9559c2388abc4a8392ff88c6
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Make this function available to libdm users. A caller outside libdm will
be added by a later patch.
Bug: 194450129
Test: mm libfs_mgr libdm_test
Change-Id: I3e3560f3cdef8978eac644d5b53cf3851209c0c2
Signed-off-by: Bart Van Assche <bvanassche@google.com>
From https://engdoc.corp.google.com/eng/doc/devguide/cpp/styleguide.md:
"Prefer using return values over output parameters: they improve
readability, and often provide the same or better performance (see the C++
Primer)." Implement this advice for ExtractBlockDeviceName(). This patch
does not change any functionality.
Bug: 194450129
Test: mm libfs_mgr libdm_test
Change-Id: I6363781163eba08e6128507b403200f472f68a59
Signed-off-by: Bart Van Assche <bvanassche@google.com>
After compiler update, infinite side effect free loops are replaced with trap
instructions. So use -fno-finite-loop to disable this behavior.
Bug: 196162833
Test: run debuggerd_test.
Change-Id: I057263360a5df64af18c17a025fab48887d0b470
There is an unclear error message if we run
`fastboot --disable-verification flash boot boot.img` on a
AVB-disabled device without a /vbmeta partition.
Error message:
terminating with uncaught exception of type std::out_of_range: basic_string
Aborted
This is because the buf->fd of the loaded boot.img is not reset,
before returning from function copy_boot_avb_footer().
Also reset some changes in copy_boot_avb_footer() from commit
If83f785e235569ee8ef0de2b37f11dbd2a9a71f4, to prevent the
unnecessary read of the boot vbmeta if no need to copy the
boot image avb footer.
Bug: 191903922
Test: `fastboot --disable-verification flash boot boot.img` on a device
without /vbmeta and without setting BOARD_AVB_ENABLE to true.
Change-Id: If84f08f1b2e12c4c6ded5cafda2bd1d30e75c662
With VAB we encourage a smaller super partition, so make sure we delete
"other" slot partitions during flashing. Otherwise, we may not have
enough space in super.
Bug: 195930130
Test: set_active, flashall, ensure other slot is deleted
Change-Id: Ic6a4f60e8f4c7abb8af7b38228753ad8ed85eedf
F2FS requires a larger minimal size than the current value of 16MiB.
Bug: 171368484
Fixes: 171368484
Test: Presubmit
Change-Id: I085d91634ada673388b07a0f5c6b1847e261b7f8
Also the check that linker configuration should not be updated if APEX
is in updatable state, is removed as now with refactoring of code and its
movement to apex project, that is also needed.
Resolves: https://b.corp.google.com/issues/192838499
Test: Run the AVD Device and check that it boots and run atest
ApexTestCases
Change-Id: I80a94fa0a4145d30546bb34a6d478a20a2881368
The main users of this instance are KFENCE and MTE-aided KASAN, which are only supported on arm64.
Skip creation of this tracing instance on 32-bit systems to save ~6Mb memory on low-end devices.
Bug: 195089948
Bug: 194719088
Bug: 194156700
Change-Id: Icaf762715fed7a282b1ad738c10bcb45dc848f4d
The user interface of Android devices becomes very slow under memory
pressure. This is because Android uses the zram driver on top of the loop
driver for swapping, because under memory pressure the swap code alternates
reads and writes quickly, because mq-deadline is the default scheduler for
loop devices and because mq-deadline delays writes by five seconds for such
a workload with default settings. Fix this by selecting I/O scheduler 'none'
for loop devices.
Bug: 194450129
Test: Built Android images, installed these and verified that the I/O scheduler of all loop devices is 'none' instead of 'mq-deadline'.
Change-Id: Ia5f606504b663948ab56955cad5a71885a356430
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Improve code readability by renaming 'device' into 'loop_device' and
'device_fd' into 'loop_fd'.
Bug: 194894000
Test: Built Android images and installed these on an Android device.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Change-Id: Ia9c2d7a525e727f8706e66631b97fc4678c6a4d9
When the device is rebooted after OTA is done,
daemon will read through all the dynamic partitions
to bring the blocks to memory. When update-verifier
runs, all the blocks would be in page-cache thereby
cutting down the boot time.
Boot time improvements on Pixel:
Full OTA:
===========
VABC (Without this patch): 37.308 seconds
VABC (With this patch): 28.604 seconds
Incremental OTA:
=================
VABC (Without this patch): 39.072 seconds
VABC (With this patch): 27.523 seconds
We read the blocks only during second stage transition. Thus,
it shouldn't impact when snapuserd is spin up during
post-install phase or during first-stage init.
Bug: 193863442
Test: Full and Incremental OTA on pixel
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: Id654449238e22125f7d6288c7100fde512cc2ced
* changes:
libsnapshot: Don't PrepMergeOps on resume
snapuserd: Add support for Xor ops in snapuserd
snapuserd: Rename Read Ahead Iterator
snapuserd: Add XorSink
libsnapshot: Clone worker readers from snapuserd
libsnapshot: Add support for Xor ops in Cow Format
When creating uid/pid hierarchy, cgroup.subtree_control should be set at
every level of that hierarchy except for the leaf level.
Bug: 195149205
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Iedc2e859715b31db62158c85016708f252db2b70
If this flag is given, then fs_mgr_mount_overlayfs_fstab_entry() shall
filter out missing directories in the lowerdir= list.
For example,
test /mnt/vendor/overlay_test overlay \
ro,lowerdir=/dir1:/dir2:/missing_dir3 \
first_stage_mount,overlayfs_remove_missing_lowerdir
should mount the overlayfs device with "lowerdir=/dir1:/dir2".
Bug: 186342252
Test: Manual boot test with modified fstab on CF
Change-Id: Id06b37d0c236528cef981e495280b4f4e9c2b4bb
Look for the fstab file in /system/etc as an alternative to /, in order
to allow fstab files to be installed using the "prebuilt_etc" Soong
module.
This new path is meant to be used by the vendor ramdisk only. As before,
fstabs should *not* be placed in /system/etc on the system partition.
In more detail: sometimes, multiple nearly-identical fstabs need to be
installed to a device, with the correct one being selected at boot time
(b/191417025 as well as other cases that partners have run into). To
avoid error-prone duplication of configuration files, these fstabs
should be generated from a template by the build system instead of being
duplicated in the source tree. But if this is done, the usual way of
installing fstabs (PRODUCT_COPY_FILES) can't be used; they need to be
made into real build system modules instead.
Currently, the "prebuilt_etc" Soong module can't correctly install the
vendor_ramdisk copy of the fstab(s), since it will install it into the
/system/etc directory whereas Android currently requires that the
vendor_ramdisk copy of the fstab(s) be placed in the root directory.
Earlier I proposed adding a "prebuilt_fstab" module to handle this quirk
(https://r.android.com/1744033). However, it was requested to instead
always look for the fstabs in /etc too, in order to allow "prebuilt_etc"
to be used and because /etc is the appropriate place for this file.
This change implements that suggestion (but actually using /system/etc,
since that is where "prebuilt_etc" actually installs it).
Bug: 191417025
Test: Tested that a device boots both with this, both before and after
http://ag/15075136 which uses the new location.
Change-Id: Id083070e51ae85959167e4615cd96b31a0b1bd6a
If we're reading up to a label, we're resuming setting up the file, and
there is no reason to expect the ops we require for sequence ops to be
present. In that case, skip prepping for merge, and return an empty
merge iterator if it is mistakenly requested.
Test: cow_api_test CowTest.ResumeSeqOp
Change-Id: Idd93bd4c4209197b9728fcb21a7191aae971b62d
This adds the ability to read the blocks corresponding to xor operations
from snapuserd. Xor Operations should be treated the same as copy
operations during the merge, but before their data is written to disk,
it must be xor'ed against the operation's data. For the purposes of
readahead, this acts as a copy op. Post readahead, it acts more like a
replace op.
Change-Id: I7d74bbdd43bfc5277ef4c8aade57dd375be9180a
Bug: 177104308
Test: vts_libsnapshot_test and cow_snapuserd_test
We can compute the xor while decompessing by computing it within a
buffer. This would allow us to use a smaller buffer than the full block
size if we wish to cut down on the extra memory required.
Bug: 177104308
Test: cow_snapuserd_test (Snapuserd_Test.xor_buffer)
Change-Id: Id18505841c77340760cea2d20e83454f1142b9b5
We'll need to have the Cow Files parsed to deal with xor ops, since
their data location is implicit from the format. Since the relevant data
is all stored in shared pointers, we can pass that data into the workers
without needing to reparse or copy.
Bug: 177104308
Test: builds
Change-Id: I96ac3da1ae620be48e5340c9f146c523b3ce74b6
This adds support for Xor Ops in the Cow Format. These represent store
possibly compressed data which must be xor'ed against the given section
of source data to be interpreted as a block in the new image. The cow
reader and writer do not have access to this data, so they assume the
provider and user of the data will handle the xor-ing.
Bug: 177104308
Test: cow_api_test (ReadWriteXor)
Change-Id: I7a313d2643773d6b81a878a3e5bc87e3bdfc387b
When running debuggerd from the command line, it's possible that
the signal will happen on a side thread. The original intercept
in tombstoned is set to only handle crashes from the main thread
pid, so in this case, the intercept doesn't occur. To fix this,
modify the code so that running debuggerd always sends the signal
to the main pid. In addition, modify the signal handler is entered
due to the BIONIC_SIGNAL_DEBUGGER signal, then the crashing tid is
set to the main thread pid instead of the current thread.
Add unit test to cover this case.
Bug: 194346289
Test: All unit tests pass.
Test: Verify the new unit test is getting the signal on the non-main
Test: thread and still properly handling the intercept.
Test: Modify the debuggerd code to send the signal to the non main pid
Test: and verify the dump still occurs correctly.
Change-Id: I2dd1bd11fc8ef4a6fe87f05ecc67ae349a101c82
There is a check here if vector resize fails. In practice, this would
throw bad_alloc or length_error and cause a runtime abort, so the check
is dead code.
To protect against bad chunk_ids we can switch to unordered_set instead.
The original memory concerns for std::set are less applicable since
unordered_set is bucketed.
Bug: 194431534
Test: apply OTA; run vts_libsnapshot_tests
Change-Id: I09c108b700d2f83acf80a9eaa5099b46aedcab89
Allow mapping of raw block devices (those without a partition table)
to partition names for first stage mount and ueventd. For example, a
block device `vdb` that contains only an ext4 metadata partition could
be mapped to `metadata` such that /dev/block/by-name/metadata is
created.
The mapping is provided by the `androidboot.partition_map` bootconfig
or kernel command line parameter.
Bug: 159943320
Test: boot with raw vdb,metadata;vdc,userdata partitions
Change-Id: Ib6a939d6fb88b85c46c81d613425a127627a734b
