This patch adds an option, readahead_size_kb in fstab entry option. It supports
to set a proper readahead_size per block/dm devices before using them by mount,
which is useful for low/high-end devices when addressing memory pressure issue.
Bug: 181567573
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: I549962e68f8488417d76bcfb283958bc33fd5d7a
As parameters are moved from kernel cmdline to bootconfig,
fs_mgr needs to be updated to handle the new location.
/proc/bootconfig should be checked first, if not present, then check
/proc/cmdline.
Test: atest CtsFsMgrTestCases
Test: launch_cvd
Test: launch_cvd with 4.19 kernel artifacts that do not support
bootconfig
Test: Both of the above configurations with --num_instances 0 or 4
Test: Both configurations with androidboot.boot_devices or
androidboot.boot_device set
Bug: 173815685
Change-Id: I23fb07a17c25c9459833cb931ced79d5ccc3e42a
This is used in cts tests to verify that algorithms in blocklist aren't
used to build the hashtree. The system properties are required to perform
the check on unrooted devices.
Bug: 175236047
Test: flash, getprop; atest CtsNativeVerifiedBootTestCases
Change-Id: I2dcfdb06f85dbe92cde45e836dd68e7bd835020f
prepare_fs_for_mount() attempts to mount() the block device at the
mount_point, so it must be created beforehand, as opposed to later in
__mount() where it is done now.
Also fix slight bugs with using fstab.mount_point instead of an
alternative specified mount_point.
Test: boot
Change-Id: I758b6a6efe2dd99433fc1974b69cb6f7ce3bc0c2
When the userdata is mounted, its result will be stored and return.
But the result is not stored when the userdata is mounted with
metadata encryption. Store the result of metadata encryption mount.
Bug: 172180818
Test: run cts-on-gsi -m CtsUserspaceRebootHostSideTestCases
Change-Id: I88b1b4f6a2b1ed81773e18243cb6c46244dc1ba5
The value of entry.mount_point for data partition is "/data"
Fixes: 5ba5b90cd6 ("fs_mgr: try tune2fs for casefolding on /data only")
Test: got "Can't mount with encoding and encryption" problem reported
by the db845c build with the default 5.4.38 prebuilt kernel
Signed-off-by: Yongqin Liu <yongqin.liu@linaro.org>
Change-Id: I226a2275f5f2ee18503c5a3863ef5a1d2c2ed7be
During boot sequence there can be multiple calls to mount_all. For the
userspace reboot to correctly remount userdata, we need to store the
return code of the one that was responsible in mounting userdata.
Test: adb root
Test: adb shell setprop init.userspace_reboot.is_supported 1
Test: adb reboot userspace
Test: checked dmsg
Bug: 166353152
Change-Id: Id0ae15f3bcf65fa54e4e72b76f64716c053af7fb
Move responsibility for setting ro.crypto.type into fs_mgr_mount_all,
so that even if setting up the filesystem fails, the type is set
correctly and so errors are appropriately handled.
Bug: 162289984
Test: simulate a failure and check that it's set.
Change-Id: Ib061a454e7e21d7206c3c1fa8e88e16618099581
The name "pre_gki_level" is causing some confusion because not all
devices launching with Android R are subject to the GKI requirement.
(See b/161563110#comment11.) E.g., devices that use a 4.14-based kernel
are exempt from GKI. However, the encryption requirements still apply.
Just use __ANDROID_API_Q__ directly instead.
No change in behavior.
Change-Id: I4242745ccc9f88e084a1adfab5796daa9bc59b6e
This reverts commit 72abd7b246
(change Ia39af3340c0e241f62557b7c2cc8b800443342f9).
When vold enables either FDE or metadata encryption, it encrypts the
filesystem in-place. Unfortunately, due to a bug, for ext4 filesystems
it hasn't been encrypting the backup superblocks.
Also, in read_ext4_superblock(), the check for
StartsWith(blk_device, "/dev/block/dm-") can return true even if the
encryption mapping hasn't been added yet, since when a GSI image is
booted the userdata block device is a logical volume using dm-linear.
The result is that read_ext4_superblock() can recognize a backup
superblock when the encryption mapping hasn't been added yet, causing
e2fsck to run without the encryption mapping and corrupt the filesystem.
https://android-review.googlesource.com/c/platform/system/vold/+/1385029
will fix this for new or factory-reset devices. However, there probably
are many existing devices that already have their backup superblocks
unencrypted. Therefore, the EncryptInPlace fix isn't enough and we have
to revert the change that started using the backup superblocks too.
Bug: 161871210
Bug: 162479411
Change-Id: I279f84c072bc6c8d3e251a5e95c78f8d6c0d50ba
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
Change-Id: I58ed723afa9975d0e93f96fad7c55465e68b3edd
Signed-off-by: Haoran.Wang <elven.wang@nxp.com>
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: Ia39af3340c0e241f62557b7c2cc8b800443342f9
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
Adding the function, fs_mgr_wait_for_file(), to ensure the
device file exists before to mount
Bug: 154278078
Change-Id: I74a68224073932773be18a79f9334d83ea5b6947
If the emmc_optimized filesystem flag is set, then like
inlinecrypt_optimized, we have to ensure that stable_inodes is set
on the filesystem.
Bug: 144046242
Test: Cuttlefish, ext4: set the flag in fstab, check for the
stable_inodes flag using tunefs -l
Change-Id: Id7f906564457c240ddf6677dd536698881385385
loop_control.h already provides loop device management APIs that we need
here. In addition, this change fixes a subtle race condition between
uevented creating a loop device node in userspace and
PrepareZramBackingDevice accessing it without waiting for it to be
created.
Test: device boots
Test: adb reboot userspace
Bug: 154500256
Change-Id: If80f18c8c337210030a6caf2aec6f7a47472b6fb
Merged-In: If80f18c8c337210030a6caf2aec6f7a47472b6fb
(cherry picked from commit c8313adf88)
loop_control.h already provides loop device management APIs that we need
here. In addition, this change fixes a subtle race condition between
uevented creating a loop device node in userspace and
PrepareZramBackingDevice accessing it without waiting for it to be
created.
Test: device boots
Test: adb reboot userspace
Bug: 154500256
Change-Id: If80f18c8c337210030a6caf2aec6f7a47472b6fb
Use realpath as a canonical representation of block devices. This makes
it easier to reason about block devices. This also fixes a bug, in which
fs_mgr_get_mounted_entry_for_userdata didn't properly work on devices
that don't support metadata encryption.
Test: atest CtsFsMgrTestCases
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 153363818
Change-Id: I139c2be46336a632bbaee86667019c075d7de814
Merged-In: I139c2be46336a632bbaee86667019c075d7de814
(cherry picked from commit 7aa37f1f21)
Use realpath as a canonical representation of block devices. This makes
it easier to reason about block devices. This also fixes a bug, in which
fs_mgr_get_mounted_entry_for_userdata didn't properly work on devices
that don't support metadata encryption.
Test: atest CtsFsMgrTestCases
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 153363818
Change-Id: I139c2be46336a632bbaee86667019c075d7de814
This steps up our garbage collection threshold over time when mounting
userdata with checkpointing=disable for f2fs. With this scheme, we step
up the percent of disk we will tolerate being unusable during
checkpointing. At 100%, the filesystem will be able to always mount.
This means we will attempt to mount at most 10 times, for a max time of
about 50 seconds.
Also logs mount time under ro.boottime.init.mount.[target]
If the device does not support checkpoint=disable:[n%], it will mount
with checkpoint=disable, which is equivalent to checkpoint=disable:0%
Test: Boot in checkpointing mode
Bug: 150506496
Change-Id: I047ff98513f4ea832e1216b91e454a57fd2e8bf6
In case of GSI on DSU, /data is mounted on the following stack:
userdata -> userdata_gsi -> actual block device, and fstab returned from
ReadDefaultFstab() function will say that /data should be
mounted onto userdata_gsi. This configuration wasn't supported.
To support it, fs_mgr_get_mounted_entry_for_userdata now unwinds the
dm-device stack /data is mounted onto, and for each entry in fstab
resolves corresponding block device (in case of logical partitions by
asking DeviceMapper to resolve name -> path, and for other cases by
reading a symlink), and then checking whenever resolved block device
belongs to the unwinded stack.
Test: on both normal boot & DSU
Test: atest CtsUserspaceRebootHostSideTestCases
Test: atest CtsFsMgrTestCases
Bug: 148612148
Change-Id: I1bb3e64ae92d56de905b4f7f1997b7499b101b0f
Merged-In: I1bb3e64ae92d56de905b4f7f1997b7499b101b0f
(cherry picked from commit f495fe798b)
In case of GSI on DSU, /data is mounted on the following stack:
userdata -> userdata_gsi -> actual block device, and fstab returned from
ReadDefaultFstab() function will say that /data should be
mounted onto userdata_gsi. This configuration wasn't supported.
To support it, fs_mgr_get_mounted_entry_for_userdata now unwinds the
dm-device stack /data is mounted onto, and for each entry in fstab
resolves corresponding block device (in case of logical partitions by
asking DeviceMapper to resolve name -> path, and for other cases by
reading a symlink), and then checking whenever resolved block device
belongs to the unwinded stack.
Test: on both normal boot & DSU
Test: atest CtsUserspaceRebootHostSideTestCases
Test: atest CtsFsMgrTestCases
Bug: 148612148
Change-Id: I1bb3e64ae92d56de905b4f7f1997b7499b101b0f
Logic of unwinding dm-device stack to figure out what entry was used to
mount userdata turned out to be a little bit more involved, and it
shouldn't be part of libfstab
This CL just moves code around and cleans API a little bit, actual fix
will be in the follow-up CL.
Test: atest CtsFsMgrTest
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 148612148
Change-Id: If0f8a765dba63adb0e6a711eb81fffdcabea3480
Merged-In: If0f8a765dba63adb0e6a711eb81fffdcabea3480
(cherry picked from commit 8f50cfc28d)
