OSDN Git Service

Fix race conditions when using mHwc off the main thread
authorSteven Thomas <steventhomas@google.com>
Fri, 1 Sep 2017 01:24:21 +0000 (18:24 -0700)
committerSteven Thomas <steventhomas@google.com>
Wed, 6 Sep 2017 20:38:44 +0000 (13:38 -0700)
commit6d8110b1708171da278782d18886fa1a21971cd9
tree58e4e4174587c9a182c022111efb2c56a03aea95
parent62948d8b502ea6e421ae1f188e34d05db8d973bd
Fix race conditions when using mHwc off the main thread

In a few cases we were accessing mHwc off the main thread without
acquiring mStateLock, resulting in crashes and other incorrect
behavior. This CL adds the missing locks. Since the locking semantics
are somewhat hard to understand, also add a clarifying comment to the
mHwc member declaration in SurfaceFlinger.h.

Bug: 64586546

Test: I manually tested normal surface flinger operation and vr behavior
on different devices, and confirmed everything looks fine. The crashes
we saw that were caused by these mHwc race conditions are hard to
reproduce, so I couldn't empirically verify this fixes the crash. I'm
relying on manual code inspection to confirm the issue is in fact fixed.

Regarding performance, I added profiling code (not part of this CL) to
check for lock contention and hold times with the newly added locks. I
confirmed that contention is low, so these calls shouldn't be
significantly slower as a result of adding the locks. The time spent
holding these new locks is also low, except for getDisplayColorModes(),
which makes a call to hardware composer service and can in some cases
take over a millisecond. That function is called so rarely though, only
once at boot, or twice at boot after a fresh flash, that it's not worth
optimizing.

Change-Id: I3854779c12a61983aaaecddb9f6316f218e519e3
services/surfaceflinger/SurfaceFlinger.cpp
services/surfaceflinger/SurfaceFlinger.h