Callers will not guarantee that they can or will ratelimit, we need to
retain the ability to blacklist snet_event_log as a result.
This reverts commit 6aa21b225d.
Bug: 26178938
Change-Id: Ibf47d2e23a84c56f5f72d02312c698df7ff2b601
Dangerous bridge to cross to whitelist, who is special, who is not?
Rationalized as these events are used to catch exploits on platform.
As it stands no one should be allowed to block any messages in the
security context, not even for development purposes.
Bug: 26178938
Change-Id: Ibdc76bc0fe29ba05be168b623af1c9f41d7edbd2
Add __android_log_is_loggable() checking for all buffers except
LOG_ID_SECURITY. Return -EPERM if blocked. Since we are sniffing
the log tag, check validity and return -EINVAL.
NB: Try not to call __android_log_is_loggable() in native code within
a signal handler. Both here, and in the system properties, there
are locking paths that are not guaranteed to play well in that
environment. This has also been the case for the log writer path
even before this change. All attempts have been made to use trylock,
and to use a more expensive code path when contention occurs rather
than lead to deadlock.
Bug: 19544788
Bug: 26178938
Change-Id: I98738c662f6328189a6703251eb8721a05e956f9
Some compilers erroneously see uninitialized use, even despite all
accesses being behind !not_locked. Confirmed initialization does not
affect expected performance.
Bug: 26178938
Bug: 26029733
Bug: 17760225
Change-Id: Ib36ed8dd2c4b196ca84ef79a9531625dcee77e15
- Deal with __android_log_is_loggable inside signal handler by
treating a lock contention system call as more costly than reading
the associated property directly. Rather waiting around in a
contended stat to hit cache.
- Check both the individual known __system_property_serial() and
global __system_property_area_serial() to detect updates or
additions to the properties to respond in the most aggressive and
timely manner. __android_log_is_loggable() return at max CPU
clockrate on a N9 in 61ns.
- Craft a common do_cache2 inline that adds the above to the other
functions that utilize cache handling and preserves (within 3ns)
performance in android_log_clockid() and __android_log_security().
These functions return at max CPU clockrate on a N9 in 23ns.
Bug: 19544788
Bug: 25693940
Bug: 25792367
Bug: 26178938
Change-Id: I9cd94598f5c558e946b93977ad3714a4b03d0422
Primarily gives access to the Chattiest TIDs and TAGs
associated with a pid.
Has a secondary effect of allowing us to pull out the
command line, comm and in some cases the associated
PACKAGE for a specific pid while the logs are still
present even if the executable is gone.
Bug: 26029733
Bug: 21615139
Change-Id: I1ea63165a680a9318360579b70b1512078ed5682
This test tells us that scatter-gather (writev instead of write)
carries a small ~2% penalty. Unaligned buffer carry a similar
additional penalty. On N9 it takes 3us to 22us _just_ to write
the pmsg logs, depending on size. Some assumptions about the
socket read and write performance for the main logging can be made
from tracking these results and should improve design decisions.
Bug: 18771697
Bug: 23685592
Change-Id: Id4d64c449140e4f39078c62b0097e403df91fe0c
If we adjusted the maximum log payload, Resolve compile
issues resulting from the changes (gTest).
Bug: 25996918
Change-Id: I672b0f4d9d4a1394a5b2e27bf81a5e906bf92a10
Adds the uid field to outgoing content for readlog applications.
AID_LOG, AID_ROOT and AID_SYSTEM gain access to the information.
Bug: 25996918
Change-Id: Ib124eca12c004cdd6e57b98e0aae6ddced385cf6
Return non-zero if ro.device_owner is set and not false
and persist.logd.security is true.
Bug: 26029733
Change-Id: Ie82ae11ae35e9c79017b6e873fefb39d79a1d4fe
logcat will crash if the log message payload is of zero length. Side
effect of possible log messages from LogKlog in eng and userdebug
builds, or lower level logging calls.
NB: The referenced bug cited an example of this native crash, this
does not fix the problem cited in the bug about the
com.android.music shutdown.
Bug: 25774695
Change-Id: I5c7a6ad8db640ba9bc8d34fab04ba7cc2a9a426a
If ANDROID_LOG_WRAP is specified, add timeout=3600 to the reader
request. logd will comply by going to sleep with the socket open.
If the start time is about to wrap or get pruned in the specified log
buffers, then wakeup and dump the logs; or wakeup on timeout,
whichever comes first.
Bug: 25929746
Change-Id: I531b4317a20abcf3ba87d78c68fa2f268a4488ab
android_log_timestamp returns the property leading letter,
it is better to return a clockid_t with android_log_clockid()
Bug: 23668800
Change-Id: I38dee773bf3844177826b03a26b03215c79a5359
android_log_timestamp returns the property leading letter,
it is better to return a clockid_t with android_log_clockid()
Bug: 23668800
Change-Id: I3c4e3e6b87f6676950797f1f0e203b44c542ed43
Although ever present, an increased regression introduced with
commit b6bee33182 (liblog: logd:
support logd.timestamp = monotonic).
A signal handler can interrupt in locked context, if log is written
in the signal handler, we are in deadlock. To reduce the contention
and chances for this problem separate out timestamp lock from is
loggable lock to reduce contention situations. Provide a best-guess
response if lock would fail in timestamp path.
Use a common lock() inline within each module, with a comment speaking
to the issues surrounding calling a function that has a mutex within
a signal handler.
ToDo: Hold off signals temporarily in mainline, restart when unblock.
Can not use pthread_sigmask(SIG_BLOCK,,) as it breaks AtCmd.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 25563384
Change-Id: I47e2c87c988c3e359eb9eef129c6a3a08e9eedef
Although ever present, an increased regression introduced with
commit b6bee33182 (liblog: logd:
support logd.timestamp = monotonic).
A signal handler can interrupt in locked context, if log is written
in the signal handler, we are in deadlock. Block signals while we
are locked. Separate out timestamp lock from is loggable lock to
reduce contention situations. Provide a best-guess response if
lock would fail in timestamp path.
Bug: 25563384
Change-Id: I6dccd6b99ebace1c473c03a785a35c63ed5c6a8a
if ro.logd.timestamp or persist.logd.timestamp are set to the value
monotonic then liblog writer, liblog printing and logd all switch to
recording/printing monotonic time rather than realtime. If reinit
detects a change for presist.logd.timestamp, correct the older entry
timestamps in place.
ToDo: A corner case condition where new log entries in monotonic time
occur before logd reinit detects persist.logd.timestamp, there
will be a few out-of-order entries, but with accurate
timestamps. This problem does not happen for ro.logd.timestamp
as it is set before logd starts.
NB: This offers a nano second time accuracy on all log entries
that may be more suitable for merging with other system
activities, such as systrace, that also use monotonic time. This
feature is for debugging.
Bug: 23668800
Change-Id: Iee6dab7140061b1a6627254921411f61b01aa5c2
- '-v epoch' prints seconds since Jan 1 1970
- '-v monotonic' print cpu seconds since start of device
- '-T sssss.mmm...' as alternate tail time format
NB: monotonic is a best estimate and may be out by a few ms
given the synchronization source clue accuracy.
Bug: 23668800
Change-Id: Ieb924b6d3817669c7e53beb9c970fb626eaad460
strcmp was 1/10 #2 behind find_property in __android_log_level(),
now virtually eliminated from performance profile.
Bug: 23685592
Change-Id: I3978886193af77e489c6d1728d6a26b7f53f8f2f
- '-v year' modifier adds the four digit year prefix
- '-v <timezone>' modifier sets and prints the timezone suffix
- Only promise in logcat to support UTC as a timezone since
all others are based on the configured environment
- '-v zone' modifier toggles the timezone suffix on or off
- '-T YYYY-MM-DD HH:MM:SS.mmm...' format is added
Bug: 23668700
Change-Id: I7521c1efb7455dc9a25434fce72a69a65dcf72ea
CYGWIN is not supported, USE_MINGW and HOST_OS==windows are being
replaced with LOCAL_..._windows variables.
Bug: 23566667
Change-Id: I3e4a1e4097dc994cf5abdce6939e83a91758fd75
* liblog does not use STL, don't link it.
* ASan runtime library depends on liblog, hence liblog can never be
sanitized.
Bug: 21785137
Change-Id: I1e97378c61d4d18d740287f5f0881427aa7cc227
