logd: cap how far back in-place sort will go to 5 seconds
Add some deterministic behavior should the user change the hour backwards when altering the device time, prevent sort-in-place and cause the logger to land the new entries at the end. Do not limit how far kernel logs can be sorted. Test: gTest liblog-unit-tests logd-unit-tests logcat-unit-tests Bug: 35373582 Change-Id: Ie897c40b97adf1e3996687a0e28c1199c41e0d0c
This commit is contained in:
parent
b280bb210b
commit
09d663229f
|
@ -370,13 +370,19 @@ int LogBuffer::log(log_id_t log_id, log_time realtime, uid_t uid, pid_t pid,
|
|||
|
||||
// assumes mLogElementsLock held, owns elem, will look after garbage collection
|
||||
void LogBuffer::log(LogBufferElement* elem) {
|
||||
// cap on how far back we will sort in-place, otherwise append
|
||||
static uint32_t too_far_back = 5; // five seconds
|
||||
// Insert elements in time sorted order if possible
|
||||
// NB: if end is region locked, place element at end of list
|
||||
LogBufferElementCollection::iterator it = mLogElements.end();
|
||||
LogBufferElementCollection::iterator last = it;
|
||||
if (__predict_true(it != mLogElements.begin())) --it;
|
||||
if (__predict_false(it == mLogElements.begin()) ||
|
||||
__predict_true((*it)->getRealTime() <= elem->getRealTime())) {
|
||||
__predict_true((*it)->getRealTime() <= elem->getRealTime()) ||
|
||||
__predict_false((((*it)->getRealTime().tv_sec - too_far_back) >
|
||||
elem->getRealTime().tv_sec) &&
|
||||
(elem->getLogId() != LOG_ID_KERNEL) &&
|
||||
((*it)->getLogId() != LOG_ID_KERNEL))) {
|
||||
mLogElements.push_back(elem);
|
||||
} else {
|
||||
log_time end = log_time::EPOCH;
|
||||
|
|
Loading…
Reference in New Issue