Improve app startup performance before the new app is in the top-app
cpuset.
Test: boots, zygote64 in top-app stune group
Bug: 159201879
Change-Id: I3aad4b4b1d2f54db9e7ba86db8a655d8552bad0a
d3ecc66b9c "liblog: support extended logger_entry headers" removed
the logger_entry::msg variable and instead uses hdr_size as an offset
from logger_entry to where the message starts in parent log_msg
buffer.
In pmsg, hdr_size is not recorded and therefore uninitialized when it
was referenced, causing corruption when reading last logcat. This
change uses sizeof(log_msg->entry) instead.
Bug: 158263230
Test: last logcat works
Merged-In: Ic01e73bf4d8ba8419cc770138565aa1210a6078b
Change-Id: Ic01e73bf4d8ba8419cc770138565aa1210a6078b
(cherry picked from commit 34d7bd98ad)
There are two locks used by AppFuseBridge.
First is it's object lock, and the second is a mutex lock in app fuse library.
There are two oppsite routines to get those locks.
(Thread A) Got Java lock -> Try to get Native lock
(Thread B) Got Native lock -> Try to get Java lock
The order must be followed to obtain two locks.
If not, the dead lock will be caused.
Therefore we change the routine to get the mutex lock first, and the object lock later.
Signed-off-by: hyeeun.jun@samsung.com <hyeeun.jun@samsung.com>
Bug: https://issuetracker.google.com/issues/145707568
Bug: 157535024
Test: atest --test-mapping apex/blobstore
Change-Id: I0ab002da9a0b7ca2f518d50ab477a080cabe3788
As the EXT4_MAX_BLOCK_SIZE defined as 65536 which reached maxium value
of unsigned int. The superblock value maybe larger than 65536. This is
found by the Integer Overflow Sanitizer.
This patch fixed below boot error when userdata is corrupted:
init: processing action (fs) from
(/vendor/etc/init/hw/init.freescale.rc:221)
init: [libfs_mgr]Invalid ext4 superblock on '/dev/block/by-name/userdata'
init: InitFatalReboot: signal 6 init: #00 pc 00000000000af7e8 /system/bin/init
(android::init::InitFatalReboot(int)+208) init: #01 pc 00000000000afbd0 /system/bin/init
(android::init::InstallRebootSignalHandlers()::$_22::__invoke(int)+32)
init: #02 pc 00000000000006bc [vdso:0000ffff9691b000] (__kernel_rt_sigreturn)
init: #03 pc 000000000004e070 /system/lib64/bootstrap/libc.so (abort+176)
init: #04 pc 000000000003427c /system/lib64/libfs_mgr.so
(read_ext4_superblock(std::__1::basic_string<char, std::__1::char_
traits<char>, std::__1::allocator<char> > const&,
android::fs_mgr::FstabEntry const&, ext4_super_block*, int*)+1804)
Test: boot with corrupted ext4 superblock
Bug: 156200421
Signed-off-by: Haoran.Wang <elven.wang@nxp.com>
Change-Id: Ib1b69bf4623f69696cb637b226ec3359fc2ed409
(cherry picked from commit cb472b92e5)
SnapshotUpdateTest uses a relatively small super partition, which
requires a small alignment and 0 alignment offset to work. For the
purpose of this test, hardcode the alignment and offset.
This test isn't about testing liblp or libdm.
Fixes: 154355449
Fixes: 157437632
Bug: 158718136
Bug: 157633441
Bug: 154646936
Test: atest on devices with alignment of data partition >= 512KiB
Change-Id: I1d0474f028cc824bd4197d0228350395239b3b81
(cherry picked from commit 31739669e91c7a3afc5bee23e43bc45fb4154667)
Merged-In: I1d0474f028cc824bd4197d0228350395239b3b81
If the superblock of /data is corrupted, fs_mgr would skip check_fs.
But, e2fsck actually may reference backup superblock to recover
the filesystem. This fix gives fs_mgr second chance to fix corrupted
ext4 /data.
Bug: 156200421
Test: boot with corrupted ext4 superblock
Signed-off-by: Randall Huang <huangrandall@google.com>
Change-Id: Ieb89e7274d772962fe37927dcd62567dd5aa4657
(cherry picked from commit 72abd7b246)
Pushed atoms do not need to be truncated because only the bytes added to
the buffer are written to the socket. Pulled atoms do not need to be
truncated because within stats_pull_atom_callback.cpp, we only copy the
valid parts of the buffer to the StatsEventParcel object.
This improves performance by avoiding a needless call to realloc.
+ removed dead benchmarking code
Test: m libstatssocket
Test: atest libstatssocket_test
Test: atest GtsStatsdHostTestCases
Bug: 158717786
Change-Id: I6965f8832758203ca566336ba12d0acaf5f756d5
This test doesn't exist on AOSP anymore, and the bugs around
alignment_offset have been fixed in R. There is no need for the test
anymore.
Bug: 157398966
Test: liblp_test gtest
Change-Id: I00ac7486faf8db8b18f764e61db1d545feb0312c
Merged-In: I563122282e940e07a7ece97ed1a9846ad1f3253c
Increase AStatsEvent max byte size to 50 KB for pulled events.
All AStatsEvent instances are treated as pulled events unless
AStatsEvent_write() is called.
- Set the default max size to 50 KB
- The starting buffer size is still ~4 KB for pushed and pulled events.
- If a write would exceed the buffer bounds, double buffer size until
write fits or 50 KB limit is exceeded in which case the overflow bit is
set to true.
- If AStatsEvent_write() is called, max size is set to ~4 KB. And if
the current payload exceeds this limit, set overflow bit to true.
- Fix error mask checking in stats_event_test.
- Set ERROR_NO_ATOM_ID when atom id is missing.
- Make sure tests don't hit ERROR_TOO_MANY_FIELDS when testing buffer
overflow.
- Rename event->size to event->numBytesWritten
Fixes: 158214941
Test: libstatssocket_test
Change-Id: Ia26aeb775f7e4f2ffe87707bab6d0119e21da10e
The same adbd module prebuilt will get used for both user and userdebug
builds in the post-APEX world, so we can't guard functionality with
product variable ifdefs anymore.
The code that was previously compiled out runs before we drop root, so
the increased attack surface essentially consists of an attacker having
control over system properties, and that likely implies that we're
doomed already (either they have filesystem control, or they have code
execution in init).
Bug: http://b/158156979
Test: treehugger
Change-Id: Ia70d3140189e5212beb813ff719355e30ca5fa04
(cherry picked from commit d076857c4f)
Adding the function, fs_mgr_wait_for_file(), to ensure the
device file exists before to mount
Bug: 158064601
Merged-In: I74a68224073932773be18a79f9334d83ea5b6947
Change-Id: I74a68224073932773be18a79f9334d83ea5b6947
(cherry picked from commit 589b7dfd83)
It's error-prone, and our specific usage of it here upsets ubsan.
Bug: https://issuetracker.google.com/158428513
Test: treehugger
Change-Id: I3a6b68865e6b4c37ac005f5f24c3d6e1de7c5bac
Merged-In: I3a6b68865e6b4c37ac005f5f24c3d6e1de7c5bac
Fix block-level checkpointing to work correctly when used in combination with
512 byte hardware sectors and metadata encryption with dm-default-key v2.
Bug: 153512828
Test: Parameter is passed to dm-bow based on first_api_level
Change-Id: Ic0a071221559271db20b06b2f17459b5b041e02d
Merged-In: Ic0a071221559271db20b06b2f17459b5b041e02d
The required block inside the definition of "adbd" does nothing: we get
the libraries it contains via direct dependency when building from
source, and not at all when using a prebuilt. Move them to a phony
rule that's explicitly listed in PRODUCT_PACKAGES.
Bug: http://b/157709367
Test: treehugger
Change-Id: I97c0889558482cfbe18ae91b39b6889d3fee877c
(cherry picked from commit e572f2fc44)
While mount_all and umount_all were updated to use ro.boot.fstab_suffix,
I neglected to update swapon_all. Trivially copied from umount_all.
Bug: 142424832
Change-Id: Icd706fe7a1fe16c687cd2811b0a3158d7d2e224e
The mount_all and swapon_all commands are documented, but umount_all
is not. Add some documentation.
Bug: 142424832
Change-Id: I7e4dcb4d222b787350a79c9e312062cac9eeb4d8
Limit the block size to 64 MB before fastboot executable binary for
windows 64-bit is released.
Bug: 156057250
Change-Id: Ic4edb963a3d99f718d7630aba3f351729a84e994
Kernel modules may be located within directories in /lib/modules.
Attempt to load kernel modules from each directory that has a name starting with
the major and minor version of the currently running kernel. If a single
kernel module is successfully loaded from a directory, that directory is
treated as the correct kernel module directory for the system. No other
kernel module directories are searched and any kernel module load errors
in that directory are fatal. If the attempt to load the first kernel
module from a directory fails, or if there are no kernel modules in a
directory, then the search proceeds to the next directory.
If no kernel module is successfully loaded from any directory as above,
an attempt is made to load kernel modules from the top level at
/lib/modules/.
Bug: 157645635
Change-Id: I92eadd8617f03a645da460ccb776bc04fa541f00
Merged-In: I92eadd8617f03a645da460ccb776bc04fa541f00
In the short term this will be used to help implement support for
multiple kernel module directories but it may be useful in other
contexts as well.
Bug: 157645635
Change-Id: I15a252b6e9394292c8f3557ed65112c935830441
Merged-In: I15a252b6e9394292c8f3557ed65112c935830441
Enable libsnapshot to export the size of the COW image, representing the
fraction of the COW device that is temporarily created in the /data
partition, computed just before initializing a merge operation.
Thise additional information can be used by other components (i.e.,
update engine) to enrich Virtual A/B metrics.
Bug: 154016862
Test: manual OTA
Signed-off-by: Alessio Balsini <balsini@google.com>
Signed-off-by: Yifan Hong <elsk@google.com>
Change-Id: I4faa0785f23884e26161e0d51268dd7a305d86bf
Merged-In: I4faa0785f23884e26161e0d51268dd7a305d86bf
(cherry picked from commit 2a1778d340)
If the first call for pullFinished fails, it is likely because the
transaction is too large. Currently, if this happens statsd will just
sleep until the timeout. With this change, the client will retry calling
pullFinish if the first attempt fails, but with an empty payload (and
with success = false) to cause the puller to fail fast, and so statsd
does not wait for the timeout.
Test: atest LibStatsPullTests
Bug: 157768117
Change-Id: I3af991fae47bb7c09bf8a6fc83f28556b836c6e4
When delivering single-stage, non-AB OTAs, the updater binary is built
on a newer OS than recovery is compiled with. libdm relies on newer ueventd
behavior which therefore breaks this model. As a workaround, we allow
libdm to fallback to the old ueventd logic if the following conditions
hold true: (1) we're in recovery, (2) the device is not an AB device,
and (3) the release is <= 10.
Since the old ueventd behavior can lead to races in libdm, this fallback
should stay as narrow as possible.
Bug: 156536673
Bug: 155202260
Test: manual test
Change-Id: I7f9da49e4ba8dfe165e0923d9918827d51d090cd
Instead of aborting when FileMap::create detects an overflow, detect the
overflow directly and fail the call.
Bug: 156997193
Test: Ran unit tests, including new unit test that aborted before.
Merged-In: Ie49975b8949fd12bbde14346ec9bbb774ef88a51
Change-Id: Ie49975b8949fd12bbde14346ec9bbb774ef88a51
(cherry picked from commit 68604b9c29)
To ensure we can shutdown cleanly, and don't hang an outstanding
requests to a FUSE host daemon that has already exited.
Bug: 153411204
Test: inspect logs during shutdown
Change-Id: I8e6479bd54dbc1fc85b087617aa6b16be9f15a3b
The FUSE filesystem is implemented by a Zygote child. If Zygote dies,
all of its children die along with it, including the FUSE daemon. The
FUSE filesystem is cleaned up automatically whenever the /dev/fuse file
descriptor of the FUSE daemon is closed. However, due to the way the
binder driver holds on to the 'struct files' of processes in the kernel,
the closing of FDs of all of Zygote's children is serialized.
That in turn means that, if a process has a file with dirty pages on
FUSE, and that FD is closed *before* the FUSE FD, the FUSE kernel driver
will happily issue a request to the FUSE daemon to serve that request.
But since the FUSE userspace daemon is already dead, it will never get
served. And because the closing of all FDs is serialized, we will never
close the FUSE fd to unblock this request.
Solve this particular case by manually aborting the FUSE filesystem when
Zygote restarts. Because we now explicitly close the FUSE fd, the FUSE
filesystem will be cleaned up, all outstanding requests to it will be
cancelled, and new ones will be skipped.
Bug: 153411204
Test: kill zygote manually
Change-Id: I2cb6c1a03cc1a932461ff33558894a428ff35180
Currently the ReadDefaultFstab function, which calls GetFstabPath,
makes some assumptions about what the fstab will be called and where
it is located. This is being used by vold to set up userdata encryption
and for gsid, and is even used in the default boot control HAL, so it
has become quite baked.
The original way for a board to specify things to mount was to use the
"mount_all /path/to/fstab" command in init.rc. However, due to the
above functionality, the path after mount_all is no longer very useful,
as it cannot differ from the inferred path, or userdata encryption and
other features will be broken.
On Cuttlefish, we have an interest in being able to test alternative
userdata configurations (ext4 vs f2fs, encryption on/off, etc.) and
currently the only way to achieve this is to either a) modify the
ro.hardware or ro.hardware.platform properties, which breaks a bunch
of things like default HAL filenames, or regenerate our odm.img or
vendor.img filesystems. We can't simply install another fstab and
point to it with "mount_all".
This change allows the fstab path to be omitted from "mount_all", and
adds another property which overrides the existing checks for
fstab.${ro.hardware} and fstab.${ro.hardware.platform}. Specifying
${ro.boot.fstab_suffix} will cause fstab.${ro.boot.fstab_suffix}
to be checked first.
Bug: 142424832
Test: booted cuttlefish with 'mount_all ${ro.hardware} --late'
Test: booted cuttlefish with 'mount_all --late'
Test: booted cuttlefish with 'mount_all --late' and fstab_suffix=f2fs
Test: partially booted cuttlefish with 'mount_all ${ro.hardware}'
Test: partially booted cuttlefish with 'mount_all'
Change-Id: I3e10f66aecfcd48bdb9ebf1d304b7aae745cbd3c
Merged-In: I3e10f66aecfcd48bdb9ebf1d304b7aae745cbd3c
