summaryrefslogtreecommitdiff
path: root/logd/LogReaderThread.cpp
AgeCommit message (Collapse)Author
2020-10-08Remove liblog, logcat, logd, logwrapperBaligh Uddin
These subdirectories have moved to platform/system/logging. BUG: 168791309 Test: Local build + TH Change-Id: Iaee2ff59d4450f3e59dc9ea8b0e257b2de53e478
2020-10-07logd: single std::mutex for locking log buffers and tracking readersTom Cherry
There are only three places where the log buffer lock is not already held when the reader lock is taken: 1) In LogReader, when a new reader connects 2) In LogReader, when a misbehaving reader disconnects 3) LogReaderThread::ThreadFunction() 1) and 2) happen sufficiently rarely that there's no impact if they additionally held a global lock. 3) is refactored in this CL. Previously, it would do the below in a loop 1) Lock the reader lock then wait on a condition variable 2) Unlock the reader lock 3) Lock the log buffer lock in LogBuffer::FlushTo() 4) In each iteration in the LogBuffer::FlushTo() loop 1) Lock then unlock the reader lock in FilterSecondPass() 2) Unlock the log buffer lock to send the message, then re-lock it 5) Unlock the log buffer lock when leaving LogBuffer::FlushTo() If these locks are collapsed into a single lock, then this simplifies to: 1) Lock the single lock then wait on a condition variable 2) In each iteration in the LogBuffer::FlushTo() loop 1) Unlock the single lock to send the message, then re-lock it Collapsing both these locks into a single lock simplifes the code and removes the overhead of acquiring the second lock, in the majority of use cases where the first lock is already held. Secondly, this lock will be a plain std::mutex instead of a RwLock. RwLock's are appropriate when there is a substantial imbalance between readers and writers and high contention, neither are true for logd. Bug: 169736426 Test: logging unit tests Change-Id: Ia511506f2d0935a5321c1b2f65569066f91ecb06
2020-10-05logd: add locks around ~SerializedFlushToStateTom Cherry
This accesses shared resources in SerializedLogBuffer and therefore requires a lock. Bug: 169736426 Test: malloc_debug_system_tests Change-Id: I807c65f4719481f933b4917a50f83f933b1929fb
2020-06-17logd: fix various clang-tidy issuesTom Cherry
In order of severity: 1) Add a CHECK() that a pointer is not nullptr, where the analyzer believes this is possible. 2) Add `final` appropriately to functions called from constructors. 3) Add missing cloexec flags. 4) Add missing `noexcept` and other subtle performance warnings Test: build with clang-tidy Change-Id: Ifd9a1299a51027a47382926b2224748b5750d6cf
2020-06-02logd: move leading_dropped logic into FlushTo()Tom Cherry
This logic isn't generic, so it should not be in the generic LogReaderThread. Moreover, it's currently broken in essentially every case except when filtering by UID, because it runs as in the filter functions before the actual filtering by pid/etc takes place. For example, when filtering by pid, it's possible to get leading chatty messages. The newly added test was failing previously but is fixed by this change. It's fundamentally broken in the tail case. Take this example: 1: Normal message 2: Chatty message 3: Normal message 4: Normal message If you read that log buffer with a tail value of 3, there are three possible outcomes: 1) Messages #2-4, however this would include a leading chatty message, which is not allowed. 2) Messages #3-4, however this is only 2, not 3 messages. 3) Messages #1-4, however this is 4, more than the 3 requested messages. This code chooses 2) as the correct solution, in this case, we don't need to account for leading chatty messages when counting the total logs in the buffer. A test is added for this case as well. Test: new unit test Change-Id: Id02eb81a8e77390aba4f85aac659c6cab498dbcd
2020-06-01logd: create FlushToState classTom Cherry
ChattyLogBuffer::FlushTo() needs an array of pid_t's to differentiate between deduplication and spam removal chatty messages, but that won't be useful to other log buffers, so it doesn't deserve its own entry in the abstruct LogBuffer::FlushTo() function. Other log buffers may need their own data stored for each reader, so we create an interface that the reader itself owns and passes to the log buffer. It uses a unique_ptr, such that the when the reader is destroyed, so will this state. FlushToState will additionally contain the start point, that it will increment itself and the log mask, which LogBuffers can use to efficiently keep track of the next elements that will be read during a call to FlushTo(). Side benefit: this allows ChattyLogBufferTests to correctly report 'identical' instead of 'expired' lines the deduplication tests. Side benefit #2: This updates LogReaderThread::start() more aggressively, which should result in readers being disconnected less often, particularly readers who read only a certain UID. Test: logging unit tests Change-Id: I969565eb2996afb1431f20e7ccaaa906fcb8f6d1
2020-05-27logd: remove LogBufferElement dependency of LogReaderThreadTom Cherry
In the future, not all log buffers will be implemented in terms of LogBufferElement. Test: build Change-Id: I5cf0d01414857b1bfa08c92a4f8035b43ef2aad7
2020-05-27logd: rename FlushToResult to FilterResultTom Cherry
This was a typo; the enum corresponds to the result of the 'Filter' function, not the 'FlushTo' function. Test: build Change-Id: Ib46f0646570b6dbaac17ae9fc95c990128cdbe72
2020-05-14logd: remove SocketClient from LogBuffer and LogBufferElementTom Cherry
In the future, we'll want to be able to write to outputs that are not necessarily a libsysutils SocketClient, for example host tests of LogBuffer. Therefore, we add a LogWriter class to be used instead of SocketClient. Test: logging unit tests Change-Id: I4385be65e14e83a635691a7ba79e9bf060e49484
2020-05-12logd: make LogBuffer an interfaceTom Cherry
We may use different implementations of LogBuffer in the future, so we make it interface and create a concrete ChattyLogBuffer class that implements it. Test: logging unit tests Change-Id: I5731d6404640664c9acc26b7c677dff3110c6a11
2020-05-12logd: refactor LastLogTimes a bitTom Cherry
There's still plenty of work that can be done here, particularly re-doing the locking so each LogReaderThread does not mutually exclude the others, but that's out of the scope here. This change primarily removes the public 'mTimes' from LogBuffer and creates a new LogReaderList class instead. It would have merged this into LogReader, but that creates a circular dependency. This change also removes the need to reference LogReader or LogReaderList from LogAudit, LogKLog, and LogListener, instead relying on LogBuffer()::log() to call LogReaderList::NotifyNewLog(). Test: logging unit tests Change-Id: Ia874b57a9ec1254af1295bfa6f7af2f92a75755b
2020-05-04logd: start cleaning up LogReaderThreadTom Cherry
1) We can use real member functions with std::thread and std::function, so use those instead of the 'me' pointer. 2) Don't expose member variables directly. 3) Rename and document member variables, since all of their references are being touched anyway. Test: logging unit tests Change-Id: I9a357a3ea8691433d58687c95356b984b83e9c36
2020-05-04logd: use std::function and lambdas where appropriateTom Cherry
Test: logging unit tests Change-Id: I7cfc63937b5dadb5547c4661ca2f5204d7b4a174
2020-05-04logd: rename LogTimes -> LogReaderThreadTom Cherry
LogTimes has evolved from being simply a store of the last timestamp that each reader has read to being a class representing an individual reader thread, including the thread function, so name it appropriately. Test: logging unit tests Change-Id: I6914824376a6ff1f7509e657fa4dc044ead62954