This reverts commit 1bef8c550c.
Reason for revert: AOSP is fixed with new vendor image
Change-Id: Ib341ac80e2f88c13a7815a490ea2d9422ebdf55f
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
selinux_denial_metadata contains device-specific information, so it is
being moved to /vendor.
Bug: 5159394
Test: bug information is still preserved in avc logs, e.g.
audit(0.0:248): avc: denied { read } for
name="u:object_r:vendor_default_prop:s0" dev="tmpfs" ino=18012
scontext=u:r:platform_app:s0:c512,c768
tcontext=u:object_r:vendor_default_prop:s0 tclass=file permissive=0
b/79617173 app=com.android.systemui
Change-Id: I23293e715b5d793a54466a128ccd57f44370cf5a
It's replaced with entries in PRODUCT_PACKAGES_DEBUG in
build/make/target/product/base_system.mk
Test: treehugger
Change-Id: I4dc69c34ddc2c494fc74bc4afee6efa240c9b0d3
logd/logcat use more symbols than the rest of the platform, so let's
statically link them for now while we understand the API that the
platform overall uses.
Test: build
Change-Id: I21ae1bd3ff9b310f099612fbe790f769712661df
- Zero initialize log_time instances by default
- Disable implicit conversions by making constructors explicit
- Explicitly initialize to EPOCH in most places
- Change sniffTime() to avoid in-place modification of a log_time
I stopped here, but we could consider following up with a more invasive
change to make log_time instances immutable and perhaps also remove the
default constructor to force explicit initialization to EPOCH.
Test: atest libbase_test netd_unit_test
Change-Id: I67e716ef74adaaf40ab2c6e2e0dddb8d309bc7ca
upon memory usage high(>log_buffer_size), logd will try to prune(erase) all those old log elements which have been read by all readers for reclaiming the memory. As such, a too slow reader will be a hinder to the success of the prune. Logd has to try to kick-out the slow-est reader when memory usage is really too high(>2 * log_buffer_size). But the kick-out operation is just a request to the reader and at what time the reader will exit is always uncertain, beyond control. Furthermore, if you kick-out reader-A, waiting for A to exit; then, another reader-B may come in; then A exit; and then you kick-out-B, waiting for B to exit; and then, ...loop for ever: yes, logd may find that there seems to be always a slow reader hinder its pruning. As we all know, that, logd will probably kick-out a slow reader(logcat), hence, indeed, almost all log capturing tools will try to re-connect logd immediately after it being kick-out-ed. Such retry makes the issue easy to happen. And, we observed that the reader thread may often be blocked by socket write operation, which hindering its exiting and hereby hindering the prune progress. We need gracefully shutdown socket to relieve it from blocking and eventually stop such disaster from happening.
Test: monkey test for one day and one night
Change-Id: I5496ff74168b71e261914b91c145aa44814a5def
LogBufferElement copy constructor supported only partial function.
Solution: handle all cases.
Test: unit test for calling the copy constructor with all possible states.
Change-Id: I55091569d98eb35a09b4c3fc068836ecd256558c
There is an issue in LogAudit::auditParse where
android::uidToName(uid) crashes with a null pointer dereference.
Include a null check on the value before passing it on.
Bug: 120043607
Test: End-to-end test with syzkaller as per instructions in bug.
Change-Id: Ic0ac5c3003fcd289ec156ce63fbd668413763429
Kernel panic - not syncing: Out of memory occurred once after 8 hours
automatic test which cases are about Summary:logd memory leak UTResult
: 1/1
IssueID: 93440
Rootcause: the method "LogTimeEntry::FilterSecondPass"(called inside
"LogBuffer::flushTo") does not check the condition flag
"LogTimeEntry::mRelease" which will be set to true when "logd" begins
to kick off a client when it finding the client is slow-est.
Therefore the client cannot be kicked off and hence the log-element
list becomes longer and longer if the slowest client reading more
slower than the writer writing.
Change-Id: I91a44a393e63b3122c15ce269ee195e0eb4339e8
Solution: add the check.
Test: logd kills slow reader
This code was accidentally deleted in the refactoring of
4f22786cc9 cause the
logd.timeout_no_start test to start failing.
Bug: 117942520
Test: logd unit tests
Change-Id: Id7994230a89d7f8c2cb1f36a8ca1175a6b398de0
LogTimeEntry's lifecycle is spread out in various locations. It
further seems incomplete as there is logic that assumes that its
associated thread can exit while the underlying LogTimeEntry remains
valid, however it doesn't appear that that is actually a supported
situation.
This change simplifies this logic to have only one valid state for a
LogTimeEntry: it must have its thread running and be present in
LastLogTimes. A LogTimeEntry will never be placed into LastLogTimes
unless its thread is running and its thread will remove its associated
LogTimeEntry from LastLogTimes before it has exited.
This admittedly breaks situations where a blocking socket gets issued
multiple commands with different pid filters, tail lines, etc,
however, I'm reasonably sure that these situations were already
broken. A check is added to close the socket in this case.
Test: multiple logcat instances work, logd.reader.per's are cleaned up
Change-Id: Ibe8651e7d530c5e9a8d6ce3150cd247982887cbe
Add FALLTHROUGH_INTENDED for clang compiler.
Bug: 112564944
Test: build with global -Wimplicit-fallthrough.
Change-Id: I40f8bbf94e207c9dd90921e9b762ba51abab5777
This change removes the call to prctl(PR_SET_KEEPCAPS, 1), because now
that logd is being run with ambient capabilities, init will set the
KEEP_CAPS / KEEP_CAPS_LOCKED securebits.
Bug: 110127913
Test: liblog-unit-tests, logd-unit-tests, logcat-unit-tests
(on an aosp_sailfish-userdebug)
Change-Id: I72b6a49c5cd1552085f9ad44cb19a7333a13eeea
This change moves logd's capabilities from being file based to being set
by init through ambient capabilities.
Bug: 62845925
Test: sailfish:/ # grep Cap /proc/`pidof logd`/status
CapInh: 0000000000000000
CapPrm: 0000000440000000
CapEff: 0000000440000000
CapBnd: 0000000440000040
CapAmb: 0000000000000000
$ capsh --decode=0x440000040
0x440000040=cap_setgid,cap_audit_control,cap_syslog
Test: liblog-unit-tests, logd-unit-tests, logcat-unit-tests
Change-Id: I28c7c4ad37ad5eafd399aef78c303ce31298a9ef
SELinux messages weren't properly filtering into the events buffer
because message_len was being used to determine length of event data
instead of str_len
Bug: 65597269
Test: SELinux denials show up in the events buffer
Change-Id: I857e10211f71dd0db33a272241c7051c5d0c59ca
(cherry picked from commit 3a5acdaa8d)
LogBuffer::log() returns either a negative number on error or a
positive number indicating the length of the message written.
Therefore, the check to notify kernel log readers of a new message
should be that this function's return value is > 0.
Bug: 78209416
Test: `adb logcat -b kernel` updates when new log messages are present
Change-Id: Icc18c0c22e62340994e5c26aedb72282d61c1541
Events in the LogBuffer are supposed to be sorted by timestamp, but for a variety
of reasons that doesn't always happen. When a LogReader is reading from LogBuffer,
LogBuffer starts at the newest event, and scans backward through the list, looking
for the last event. Previously it would accept a couple that were a little bit out
of order, but if it found one that was ancient, it would just bail. This change
removes that check for the ancient messages. They are probably indicative of
something else upstream, but since there is no invariant of the list being sorted,
this change simplifies the search algorithm, and makes it look only at the previous
300 events.
Bug: 77222120
Test: while true ; do frameworks/base/cmds/statsd/run_tests.sh 2h ; done
Change-Id: I0824ee7590d34056ce27233a87cd7802c28f50e4
(cherry pick from commit 22712428b8)
Discovered while running AddressSanitizer, binary events were fed
into logd that were smaller than the binary event string header.
Fix is to check the buffer sizes before performing the memcmp
operation.
Test: compile
Bug: 74574189
Change-Id: Ic01ef6fb0725258d9f39bbdca582ed648a1adc5d
While running AddressSanitizer, binary events were fed into logd
that were smaller than the binary event string header. Fix is to
check the buffer sizes before performing the memcmp operation.
Test: compile
Bug: 74574189
Change-Id: Ic01ef6fb0725258d9f39bbdca582ed648a1adc5d
