Now that FindPlatformDevice() isn't modifying the path argument, and
is just passing it on to FindSubsystemDevice(), take this argument by
const reference. That should avoid an unnecessary string copy.
Bug: 316324155
Test: Compile
Change-Id: I1d92a322d0c311ee46a117dd9d650896ec02520f
Revert submission 3334193-no-llndk-versioning
Reason for revert: Droidmonitor created revert due to b/378038995. Will be verifying through ABTD before submission.
Reverted changes: /q/submissionid:3334193-no-llndk-versioning
Change-Id: Id8d85be1930bef68f94cee66a0fe29278de48d64
* changes:
init: Add the ability to find the boot device by partition UUID
init: Move the stripping of "/devices" and "/devices/platform/" to a helper
init: Break FindPlatformDevice() into a helper function
init: Factor GetBlockDeviceInfo() out of GetBlockDeviceSymlinks()
init: Use ConsumePrefix() instead of open coding in GetBlockDeviceSymlinks()
This reverts commit a2bd0e6b5d.
Reason for revert:DroidMonitor: Potential culprit for http://b/377739155 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: I4c2b686aaf291db819d37711d4427d0094ca2295
The current code waits for boot partitions to show up by waiting to
see a uevent with the right partition name. However, nothing in the
waiting code validates that the partition that showed up is actually
on the boot device. That means that the current code can be confused
if there is another block device in the system (possibly connected via
USB) that has a partition name matching one of the system ones.
It can be noted that the problem is specifically just that the
"waiting" part returns too early. Later parts of the system,
specifically the parts of the system that create the
"/dev/block/by-name" symlinks, do properly look at the list of "boot
devices". This means that the problem we're fixing is that later code,
which assumes that the boot partitions have already initialized, can
fail to find an initialized partition.
To make it concrete, imagine that you have two block devices in your
system: the builtin emmc and an external USB disk. Let's say you're
booting over USB and "boot_devices" properly lists only USB. Both the
"emmc" and "USB" block devices are properly formatted Android disks
and have the full slew of partitions. At boot time, you can see:
1. We get to the point where we need to wait for the "boot" source
(USB) to show up.
2. We see the eMMC show up.
3. The eMMC has all the needed partitions, so we consider our wait
done. ...but eMMC isn't in the list of "boot devices" so we don't
create the "/dev/block/by-name" symlinks.
4. Later code assumes that the "/dev/block/by-name" symlinks are
already setup and fails.
5. The device fails to boot.
Fix it so that the wait makes sure that the partitions are on the boot
device.
Unfortunately, it appears that in some cases products (especially
emulators) aren't setting the "boot devices" and/or are not making
sure all boot partitions are on the same device. Limit the fix to only
devices using the new "boot_part_uuid" to make sure we don't break old
code.
NOTE: this is effectively the same change as a previous one ("init:
Look for super partition only on a boot device") but with the added
fix to only enable the check when using "boot_part_uuid".
Bug: 309244873
Bug: 349144493
Bug: 316324155
Test: Boot isn't confused when two boot devices are present
Change-Id: Iaae453ed661307f485cdf4dde86294105cae9b2d
The current mechanism for specifying boot devices on Android systems
involves passing a set of "boot_devices" though command line,
bootconfig, or device tree.
The bootdevices are specified as strings and, in general, need to
match a sysfs path but without the "/sys/devices" or
"/sys/devices/platform" prefix. The sysfs path is generally the path
to the closest parent of the block device that is a "platform" device.
As an example, if the sysfs path of the expected boot device is:
/sys/devices/platform/soc@0/7c4000.mmc/mmc_host/mmc1/mmc1:0001/block/mmcblk1
The bootloader would specify it as "soc@0/7c4000.mmc" since:
* We strip off "/sys/devices/platform/"
* As we move up directories, we don't find one whose subsystem is
"platform" until we get up to
"/sys/devices/platform/soc@0/7c4000.mmc".
The current mechanism is a bit brittle. Specifically:
* The sysfs path isn't _really_ stable and can change across kernel
upgrades. For instance, during one kernel upgrade the device tree
for a product changed so that the root node changed from "soc" to
"soc@0" and this changed all sysfs paths. In the past device tree
folks have asserted that we shouldn't rely on dts node names to stay
consistent, yet those node names are used to construct sysfs paths.
* For some devices, like USB, the path of the closest "platform"
device tends to be the path of the USB controller. This means that
if two USB disks are plugged in we can't guarantee which one will be
identified as the boot device.
Add a new method of finding the boot device by passing the partition
UUID that we loaded the kernel from. Using the partition UUID to
identify the boot device is standard on Linux. You can see this
because when you're not using an initramfs you can use the syntax
"root=PARTUUID=<valid-uuid-id>[/PARTNROFF=n]" to specify the root.
Using the same idea for Android's boot code makes sense.
With this new method for finding the boot device, we can make the code
much more specific about matching sysfs paths. Once we find the sysfs
path for the kernel we can make sure that all of the other boot
partition share the same "scsi" or "mmc" parent instead of going all
the way to the closest platform device. In the above example, this
means that we'd make sure that all boot devices are found under this
sysfs node:
/sys/devices/platform/soc@0/7c4000.mmc/mmc_host/mmc1/mmc1:0001/block/mmcblk1
...instead of just making sure they are under:
/sys/devices/platform/soc@0/7c4000.mmc
There is the question of what we should do if the bootloader passes
_both_ an old style "boot_devices" and also a partition UUID. In this
case, we'll issue a warning and then ignore the old "boot_devices".
Considering it a warning rather than an error could allow switching to
the "boot_part_uuid" method even if an old bootloader is still
hardcoding some old "boot_devices".
NOTE: Using partition UUID won't cause any security problems even
though someone _could_ plug in an external device crafted to have the
same UUID as the normal boot device's kernel partition. We already
have "verity" in the system making sure our filesystems are not
tampered with and this would also protect us from booting a tampered
disk. That means that the worst someone could do in this case would be
to confuse the system and make the device non-bootable. Chromebooks
have been using the partition UUID to find the root filesystems for
years and this has never been a problem.
NOTE: this new method relies on the commit ("init: Add partition_uuid
to Uevent") which in turn relies upstream kernel commit 74f4a8dc0dd8
("block: add partition uuid into uevent as "PARTUUID"").
Bug: 316324155
Test: Use partition UUID to boot
Change-Id: If824cb700ca3696a442a28e6ad02d7c522c3b495
A future change will want the same stripping when looking for USB boot
devices. Move the stripping down to the helper.
This change is intended to be a no-op and just a reorganization.
Bug: 316324155
Test: See boot devices still found
Change-Id: I025d9d68fedf652055454cbd93e15f480b6056dd
We want to use the logic for FindPlatformDevice() in a future change
to look for devices that have USB parents. Break out a helper
function.
This change is intended to be a no-op and just a reorganization.
Bug: 316324155
Test: See boot devices still found
Change-Id: Ic5a57a89339c43dea1334644be9386637169c61c
Later code will want to use GetBlockDeviceInfo(), so factor it out to
a helper function. This change is intended to be a no-op.
Bug: 316324155
Test: Build & boot
Change-Id: If5d63f39efcd84a07eb8c6fa4f28bda45c4cbe5c
In GetBlockDeviceSymlinks() we may need to strip the
"/devices/platform/" or "/devices/" from a string. Use the helper
ConsumePrefix() to do this, which is more convenient and readable.
This change is intended to be a no-op and just a cleanup.
Bug: 316324155
Test: Build and boot
Change-Id: I1adb1906ec37ff8f6f505abc5f26e1e3b157e608
This partially reverts commit de6707df0c.
Reason for revert: code change landed, now modifying JSON file only
Original description:
To improve input latency, set the critical input threads to RT priority.
This will use RT priority on AOSP devices by default. OEMs can still
choose to customize what "input policy" means for their device, which
may not necessarily mean RT.
For example, on device with multiple small / big cores, input task
affinity could be changed to prioritize big cores + higher CPU frequency
/ voltage, but still keep the standard / default input thread priority.
With this patch, I'm finding that sometimes, one of the critical input
threads has priority 100 instead of the expected 98. Still looking into
that specific issue, but the issue is already present with the existing
"input policy" code.
Bug: 330719044
Flag: com.android.input.flags.enable_input_policy_profile
Test: took perfetto trace and checked the priority on InputDispatcher
and InputReader threads.
Change-Id: I7d8a941f36ad9e4b75a7a0f4c5d81895256d6919
* changes:
init: Reorder GetBlockDeviceSymlinks() so FindDmDevice() is first
init: Add partition_uuid to Uevent
fs_mgr: Add getter for androidboot.boot_part_uuid
Versioned LLNDK symbols are guarded with __builtin_available.
Bug: 362658565
Test: m --no-skip-soong-tests
Change-Id: I0fb3bc87b74da62b8a8fba0c5bb6a3373e6a55dc
By moving FindDmDevice() it's easier to unify the code with the
IsBootDevice() function. In this case the order doesn't matter since
anything with the uevent path "/devices/virtual/block/dm-" (the only
devices FindDmDevice() looks at) won't match any of the other sections
of the if/then/else test.
Bug: 316324155
Test: Build & boot
Change-Id: I819eb60aa5077f0eb2c2f2783b152e43a52ba8b7
As of commit upstream Linux kernel commit 74f4a8dc0dd8 ("block: add
partition uuid into uevent as "PARTUUID""), it's easy to include the
partition UUID in the Uevent structure. Add it in so that other parts
of the init code can make decisions based on the partition UUID.
If this code is run on older kernels we'll never see the partition
UUID and it will be left blank.
Bug: 316324155
Test: Run w/ a newer kernel and see partition_uuid populated.
Change-Id: I48a52aa006c05023f7f1cc5cc0ab5c1f1ec37455
In order to make booting from some media types (like USB) more robust,
the bootloader will be extended to support passing the partition UUID
that it loaded the kernel from. It can pass this via kernel
commandline or via bootconfig. Add a way to get this.
Bug: 316324155
Test: Use the getter in a future change
Change-Id: Iab04742c0f2666db18dc48bcaaa2869eba405748
If server disconnects, then handle the empty response.
Bug: 377068272
Test: Full OTA
Change-Id: Ic48204c457ef924ba9a3c1ae84a3317fb1ccda04
Signed-off-by: Akilesh Kailash <akailash@google.com>
This reverts commit de6707df0c.
Reason for revert: changing code without modifying JSON file now
Original description:
To improve input latency, set the critical input threads to RT priority.
This will use RT priority on AOSP devices by default. OEMs can still
choose to customize what "input policy" means for their device, which
may not necessarily mean RT.
For example, on device with multiple small / big cores, input task
affinity could be changed to prioritize big cores + higher CPU frequency
/ voltage, but still keep the standard / default input thread priority.
With this patch, I'm finding that sometimes, one of the critical input
threads has priority 100 instead of the expected 98. Still looking into
that specific issue, but the issue is already present with the existing
"input policy" code.
Bug: 330719044
Flag: com.android.input.flags.enable_input_policy_profile
Test: took perfetto trace and checked the priority on InputDispatcher
and InputReader threads.
Change-Id: I3dabf4da0398324cf542e701c103551343b883cf
This reverts commit 930f77b02c.
Reason for revert: DroidMonitor: Potential culprit for http://b/376665573 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: I9b9914703946f1eb4e40e779aa9cb5154ea108d3
