Add a 2s timeout for logd command socket operations:
android_logger_clear
android_logger_get_log_readable_size
android_logger_get_log_size
android_logger_set_log_size
android_logger_get_statistics
android_logger_get_prune_list
android_logger_set_prune_list
That correspond to:
logcat -c
logcat -g
logcat -G
logcat -S
logcat -p
logcat -P
These operations should return immediately in typical circumstances,
but if logd is stuck, they would otherwise block indefinitely. This
allows the commands to gracefully timeout instead.
Test: kill -s STOP `pidof logd`; logcat -g (and other options)
times out appropriately
Test: logcat -g (and other options) work successfully otherwise
Change-Id: I6c4671a9b3daa4a454c0a14ae7d0b7d3b08be77a
The fuzzer was creating individual maps that overlapped with other maps.
Since this is not possible in the real world unless the kernel is broken,
do not let the fuzzer do this. This resulted in memory leaks, because some
parts of the code have this assumption baked in.
Bug: 160895854
Test: Ran fuzzer test case that leaked memory and verified it no longer does.
Change-Id: I9f3c1e28781093b041b747e1566fb51d40d2bf71
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
Only the parent executable, not libraries should set this value.
Note that `modprobe` in toolbox and first stage init, the two primary
users of this library already set this same minimum log severity.
Test: build
Change-Id: I888968deede3323cc270efc3cfd1b40fc521d2da
This is correct significant figures/units based on the precision of our
measurements, but it does not reflect our actual certainty re the output
data, since in reality, confidence is diminished by temperature, device,
hardware revision, time of day/month/year, spurious activity, data
connectivity, app install list, inherent randomness of multiprogramming,
sensor activity, user interaction, /data caches, build-by-build
differences, charging state, data fragmentation, race-driven sleeps,
cosmic radiation, factory defects, local magnetic or gravitational field
differences, changes in device momentum, or other known and unknown
causes.
Bug: N/A
Test: run perfboot.py, and output has:
mean: 10801 ms
median: 10801 ms
standard deviation: 18 ms
Change-Id: I796396acc203b29e9a14e4d6dffa58db7b8cd9fb
Don't cache the property size values since they're only queried at the
start of logd and only once during dumpstate. Initializing
SerializedLogBuffer, which includes all of the logd queries, takes
under 100us without the cache, certainly fast enough that this cache
is unneeded.
Move these functions to their own file in preparation for removing
them from liblog.
Test: log sizes set appropriately
Change-Id: I15a2fd687dcffb4eab2f22ee0825ca86e40cdba3
Until 77fdb22cf6, logd started as
AID_ROOT and then dropped its privileges. Since then, there's been no
reason to use string comparisons rather than checking the uid.
Test: pkill -SEGV logd
Test: treehugger
Change-Id: Ia709f8f59cb0ab9abac7df84c96c701b5d0a83ea
Apparently these tests are run in parallel, which causes errors since
they use the same log tag. Use unique log tags based on pid to fix
this.
Also re-enable the previously disabled tests.
Bug: 162669552
Test: run these tests 100x+ and see that they no longer fail
Change-Id: Ib20d638e5e559bca23adec479a5dcf64075e376e
* Supports sending memfds in addition to data from an iovec
* Also add a basic test called send-fd
Bug: 117221195
Test: Run send-fd with corresponding Trusty application.
Change-Id: I562d2ff744938c868323a016659ca1332f6a576b
1) All current users are better off ignoring SIGPIPE at the beginning
of their process instead of ignoring it just for SocketClient
2) This isn't thread safe if users did want it, since sigaction()
ignores SIGPIPE for the entire process
3) This costs 5-10% of logd CPU time when logcat is reading logs
Also clean up the error handling in SocketClient::sendDataLockedv().
Test: kill logcat and see that logd doesn't crash
Test: run simpleperf and see that no cycles are going to sigaction
Change-Id: I6532c8a0d71338e534411707b9a9bd785145c730
Add 'print_all_logs' which is equivalent to running `logcat` from the
beginning of the captured log buffers.
Test: all logs can be replayed from the start
Change-Id: If0e25513fb294e61c834f82fbf90468c4b767424
On GKI updates, has_dynamic_partition_metadata() may be false. Even if
it is the case, partial_update_ should be set properly.
Test: apply GKI update
Bug: 162616968
Change-Id: Icf055d8eb3060e36b3e977541a24f62f9fe11a6f
