Consolidate command handling for commands that take a buffer ID as
their first argument. Further use ParseUint instead of atoi(), since
atoi("bad string") returns `0` is the same as LOG_ID_MAIN.
Test: these commands are handled property
Test: `echo -n 'getLogSize ignoreme!\0' | nc -U /dev/socket/logd`
returns an error
Change-Id: I3e84a6157e16f4c110681da453e1ae1a920da7c4
liblog exposed __android_logger_get_buffer_size() which queries log
size properties, but that should not be a generic library function.
Logd should be the only process that queries these properties and
other processes should query the actual used log sizes from logd via
the android_logger_get_log_*_size() functions.
Also, always use 1MB for log buffer tests, instead of just on host and
various other clean up related to improper types.
Test: log buffers are correctly sized
Merged-In: I9b7c86bf58e569618737afe9097cf1c4d4e61d95
Change-Id: I9b7c86bf58e569618737afe9097cf1c4d4e61d95
The set of linked binaries was making it difficult to run
the test over a native bridge. Since init won't usually
run over a native bridge, the test can be skipped.
Bug: 161081809, 142324733, 162288553
Test: Arm build of CtsInitTestCases skips rammus-arc-r Chromebook.
Change-Id: Icdd8b03111d0f3fd6658ee6d9a97fca27181db45
(cherry picked from commit 9cecf8422a)
There is a possibility of data loss if an interrupt occurs in the
middle of these write() calls.
Test: logcat -g/-S/-B work correctly
Change-Id: I2dd4ec10771714fc49b61538d3028983516e106c
There is an existing API, android_logger_get_log_readable_size() which
historically reported the consumed amount of data for the chatty log
buffer, since consumed and readable are synonymous with that buffer
type.
With log compression, readable and consumed are not synonymous, since
the readable log size is the uncompressed log size whereas the
consumed log size is the compressed log size.
This change adds android_logger_get_log_consumed_size() which returns
the consumed log size and makes android_logger_get_log_readable_size()
return the readable log size. Note that these values are identical if
compression is not used.
It adds both statistics to logcat:
main: ring buffer is 1 MiB (429 KiB consumed, 817 KiB readable)
radio: ring buffer is 1 MiB (339 KiB consumed, 715 KiB readable)
...
Test: logcat prints the right values with compression and chatty
Change-Id: I8b9688a987736204e2e6026e8635fbd1a5e68bb7
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
ro.debuggable is set by init before other processes would possibly
call __android_log_is_debuggable(), so this property can be checked
once and stored without liblog's property caching mechanisms.
Test: this function returns accurately
Change-Id: Idb1e5e10e53ca809b7f9a75164a4982f39827d4e
