In order to create symlinks for USB and block devices, the path for
their parent platform device must be known.
Previously, ueventd would save each platform device that it encounters
to a list and query this list when creating the symlinks. That,
however, is racy because the uevent socket does not differentiate
uevents from RegenerateUevents() and uevents sent by the kernel when
probing a device first the first time. The below scenario is the
faulty case:
1) Kernel probes parent platform device for a block device
2) ueventd calls RegenerateUevents() and starts processing uevents
3) Kernel probes block device and sends its uevents
4) ueventd picks up the block device uevent during its uevent processing,
without yet regenerating the platform device uevent, causing improper
symlinks to be created.
This change stops storing the platform devices in a list, and instead
traverses up the directory structure for each USB or block device
until it reaches a platform device, defined as one whose subsystem is
the platform bus. This fixes the race and simplifies the ueventd
code.
Bug: 62436493
Bug: 62681642
Test: Boot bullhead
Test: Boot sailfish
Test: Init unit tests
Test: Boot hikey + hotplug/unplug sdcard
Change-Id: I21636355d8e434f30e0cba568598a6cf139e67f9
ueventd already does restorecon() for /sys/{block,class,devices}, so
instead of duplicating this effort with init, move the restorecon()
that init does for all of /sys to ueventd.
Bug: 62420036
Change-Id: I6125f8ff5316a0cf45872d1100d089d71802958f
Merged-In: I6125f8ff5316a0cf45872d1100d089d71802958f
Test: Boot sailfish, bullhead
Fix a couple of memory leaks in tests.
Fix a potential case that length could be zero.
Bug: 23762183
Test: Ran unit tests, then ran valgrind on unit tests and verified no leaks.
Change-Id: I5f7602aa0204db0488a8e305250658cdb6e977d0
ueventd already does restorecon() for /sys/{block,class,devices}, so
instead of duplicating this effort with init, move the restorecon()
that init does for all of /sys to ueventd.
Bug: 62420036
Change-Id: I6125f8ff5316a0cf45872d1100d089d71802958f
Test: Boot sailfish, bullhead
Make them available to tests so that they can compare values
directly instead of comparing error code strings.
Test: zip_archive_test
Change-Id: I1c78c24651ff7549b5125a49a4e67bbd8295c617
Relax the shell command length limits when talking to an adbd with the
shell protocol.
shell is pretty much the only service that takes an arbitrarily long
string, so this is somewhat safe.
Bug: http://b/37716055
Test: `adb shell $(python -c 'print "echo " + "f" * (32*1024)') | wc` on L and master
Change-Id: I0737fd2244530ef8080f300cd3a3549a1ab93465
restorecon_recursive may take a long time if there are a lot of files on
the volume. This can trigger a watchdog timeout in any process that
tries to set a property while it is running. Fix this by running
restorecon_recursive in its own process.
See https://jira.lineageos.org/browse/BUGBASH-555
Change-Id: I2ce26ff2b5bfc9a133ea42f4dbac50a3ac289c04
Commit 795267d4c7 ("Removed cpusets/schedboost build time dependency.")
turned the cpusets and schedtune options into runtime
decisions.
However the kernel option which is mentioned in the
code comment (CONFIG_SCHEDTUNE) is very misleading
as it doesn't exist (CONFIG_SCHED_TUNE does exist)
and it doesn't describe the real functionality of
the method. schedboost_enabled() will still return
false if CONFIG_SCHED_TUNE is set in the kernel but
CONFIG_CGROUP_SCHEDTUNE is not.
So to clarify this, we need to change the comment
to reflect that CONFIG_CGROUP_SCHEDTUNE, which depends
on CONFIG_SCHED_TUNE, is required.
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
