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
SerializedLogChunk.three_logs assumes that log buffers are
zero-initialized, but they are not. This causes test failures on
host.
Test: this test passes
Change-Id: I0dfa282bdc36eaa4e8e39d85c5227f717b45ec2a
The error was meant to imply "without the filename" but (a) that wasn't
spelled out and (b) anyone who did just try the command would probably
be unpleasantly surprised by the massive amount of spam on their
terminal. So give them copy & paste instead.
(I did consider using their supplied filename, but since that's almost
certainly blah.zip, it seemed uncool to silently create a large text
file called "something.zip"!)
Bug: http://b/170225883
Test: untested for lack of a working pre-N device right now
Change-Id: I834939c963ca09927ccd4dc5ed8e88c65455838e
Too many vendors assume that this is included, and it's not worth the
effort to clean up.
Bug: 165825252
Test: build
Change-Id: Ib99f0de4aac64134c21c0ee09f7ea576ebd0fe9e
This accesses shared resources in SerializedLogBuffer and therefore
requires a lock.
Bug: 169736426
Test: malloc_debug_system_tests
Change-Id: I807c65f4719481f933b4917a50f83f933b1929fb
Too many vendors assume that this is included, and it's not worth the
effort to clean up.
Bug: 165825252
Test: build
Change-Id: I42fb32be7e5e3201dfc5c58734e3ef5b9251faf1
Revert "Link to libsnapshot_cow everywhere libsnapshot is linked."
Revert submission 1433573-vab-libsnapshot-linkage
Reason for revert: b/169981170, update crash for droidfooders.
Reverted Changes:
Ie75bba98c:Link to libsnapshot_cow where libsnapshot is linke...
Ieedfadc55:libsnapshot: Partially implement OpenSnapshotWrite...
I28a5d4a88:Link to libsnapshot_cow everywhere libsnapshot is ...
Exempt-From-Owner-Approval: Revert to unblock dogfood
Change-Id: I0677df77672aca9fd54d94e009ac0be7c88a1a9d
Remove WrappedPrivateKey and select wrapped vs plaintext key command
based on format instead.
Bug: 154033394
Test: send wrapped test key. Not yet accepted by trusty
Change-Id: I3b0a29be78f2a8e84ebd990713f66788256d8e3f
Mark a CIE with a S in its augmentation string as signal frame.
This allows the code to properly handle signal frame data if none
of the signal frame pattern matchers work.
For a signal frame, DwarfSectionImpl<AddressType>::Eval needs to
continue the unwinding even if PC is zero. A zero PC means that the
program has crashed, and we should try to recover the real PC using the
return address on the stack or LR. This behavior is tested by
UnwindOffline.signal_{x86,x86_64}, which modify the libc.so files
so that the signal frame pattern matcher fails and the CIE/FDE
data is used instead.
Test: libunwindstack_test
Change-Id: I4655b070028fd984345311a5e743796f8c30ed36
Add ".check_key_programmed = true." for RPMB_REQ_DATA_READ such that
we can check whether the rpmb key has been programmed before executing
RPMB_REQ_DATA_READ command.
"JEDEC STANDARD Universal Flash Storage (UFS) Version 3.0" specifies
that data access before the key has been programmed should return
“Authentication Key not yet programmed” (0007h)..
Bug: 152901318
Test: Trusty storage tests
Change-Id: I4759fbce5f37234090a22a1d9dc3b38072f6ecaf
1: Create a static library which exposes APIs
to manage snapuserd daemon.
2: Snapuserd daemon creates communication socket.
Bug: 168258493
Test: cow_snapuserd_test tests all the library API
along with the IO path from dm-snapshot.
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I8aaedf89d75e793c145fdad248a4d88e0ce8348c
Missed a review point made, added the license header to FuzzFormatTypes
Test: Compiled code
Signed-off-by: Dylan Katz <dylan.katz@leviathansecurity.com>
Change-Id: Ib8f32b802ec207d0483772c38a0a741e0dd1f151
The README.md states that this ordering is not guaranteed to give
flexibility for the future, however it's time to state that this
ordering is guaranteed, especially since:
1) We have a tests, EventTriggerOrder and
EventTriggerOrderMultipleFiles, which have guaranteed this ordering
since 2017.
2) We have users requesting and depending on this order
Also update some slightly out of date parts of the documentation:
1) We import /system/etc/init/hw/init.rc instead of /init.rc as the
first import
2) We additionally import /system_ext/etc/init and /product/etc/init
Test: n/a
Change-Id: I6d7b8d9e52f0d52bee320d5074ebb74a537f9150
When Android userdata partition has been erased in fastbootd, call
oem specific API doOemSpecificErase() to wipe other userdata in
device.
If oem doesn't implement this specific API in fastboot_hal lib,
fastbootd will receive 'NOT_SUPPORTED' return status.
Bug: 169173873
Change-Id: I9b6a5a4aaed31d1168e633418b189f9bb6d34d01
Tom Cherry