Don't follow symlinks. Suggestion from Jann Horn.
Also, add O_CLOEXEC. This prevents file descriptor leakage should
this code ever run in a multithreaded environment.
I'm not sure if either of these changes actually address any
security concerns, but it's harmless, so go ahead and add it.
Bug: 15675141
Change-Id: I7ba4e9d10439b7150f59759b54e3ad8ccba411e3
Port libcutils memset16/32 assembly SSE2 optimizations to x86_64
architecture. Ensures the same performance on 64-bit arch.
Change-Id: I874a71a884c0d28a152933ddff9cb886c9a6e99e
Signed-off-by: Henrik Smiding <henrik.smiding@intel.com>
Not seeding this each call should help reduce collisions when multiple
threads are calling ashmem_create_region. Also cleaned up code by
deleting gotos, and making formatting consistent.
Bug: 15394258
Change-Id: Iafdaea57b2317e0eb7c40d7b5595c523814fd88c
In some condition, some of FS would set disable_roll_forward option.
In this case, when we do power off or reboot, the power down progress
would stuck at android_reboot for 360 sec.
The reason is, remount_ro_done function check key word "rw" to determine
whether all the read-write FS has been remounted as read-only FS.
Unfortunately, it takes disable_roll_forward as a rw flag too by
mistake, so the check would always fail, until reach 360 sec threshold.
The patch would match "rw," from mount options, this can avoid the issue
successfully.
Change-Id: I409f9dc88c9ee5cf049615ea9dcccaf195b6bc5a
Signed-off-by: Hong-Mei Li <a21834@motorola.com>
After a disconnect, the initial blocking connect takes
a long time to return, while subsequent calls return
quicks. Switch to a non-blocking connect to make the
re-connect time more consistent and faster overall.
Change-Id: I21d02b22a8eb9a457c2f1fa95eb17894d5612ccd
Signed-off-by: Ken Lierman <ken.lierman@windriver.com>
Reviewed-by: Gumbel, Matthew K <matthew.k.gumbel@intel.com>
Reviewed-by: Jovanovic, Radivoje <radivoje.jovanovic@intel.com>
Reviewed-by: Boie, Andrew P <andrew.p.boie@intel.com>
Bionic needs to re-raise various signals, which means the si_code
debuggerd sees has been clobbered. If bionic sends us the original
si_code value, we can use that instead of the one we see when the
ptrace the crashed process' siginfo.
Change-Id: If116a6bc667d55a6fb39b74f96673292af4e4c8c
Adds Silvermont specific cache sizes for memset16/32 SSE optimization.
Change-Id: Ib5ea086d57544e74ac384ee1ef516b8511392f70
Signed-off-by: Henrik Smiding <henrik.smiding@intel.com>
* Read out system properties with same syntax as SystemProperties.java
* Also adds unit test suite to validate correctness of properties
* Also fixes buffer overrun in property_get
Change-Id: Ifd42911f93e17da09e6ff1298e8875e02f3b6608
A normal sequence of calls is as follows:
str_parms_create_str, str_parms_add_str, str_parms_destroy.
In some cases the destroy caused double free.
str_parms_add_str will clone the input and send it to hashmapPut
for storage. If hashmapPut did not store the strings it will raise
errno = ENOMEM and leave caller with ownership of the strings.
In any of these cases it will be safe to destroy the str_parms.
But what if it wasn't hashmapPut that said NOMEM? What if there
was a stale NOMEM already before a successful hashmapPut?
In that case the strings will be successfully added to the list
(if new), but when str_parms_add_str sees the NOMEM it will free
them anyway, leaving dangling pointers in the str_parms!!
It is the responsibility of the caller to clear errno before any
interesting call. This patch makes sure that str_parms_add_str
reacts only on errno emmitted from hashmapPut.
Change-Id: If87e4bcc482f09e1c66133d33517b152ebdac65f
Nick Kralevich