SurfaceFlinger/LayerRenderArea: Hold lock while modifying hierarchy

Multiple issues are seen in RenderArea when destroying
the screenshotParentLayer container layer used by LayerRenderArea.
This code executes on the main thread without a lock. Our rules for
locking in SurfaceFlinger are like this:
	1. The main thread will hold the lock when writing
	to the state, and be the only writer
	2. Anyone can read the state if they hold the lock
	3. Main thread can read from the state without the lock
	since it is the only writer.
LayerRenderArea's reparentForDrawing operation violates these rules
by updating mDrawingParent without holding the lock. If there were
some other binder thread which was accessing the hierarchy (say calling
getAlpha on a layer in the hierarchy descending from our screenshot
layer), we could have a sequence like this:
	1. Other thread calls mDrawingParent.promote(), on the wp
	we provided constructing ReparentForDrawing
	2. At the same time we destroy ReparentForDrawing and overwrite
	the wp
	3. This causes wp::~wp and wp::promote to interleave
	4. While the wp counters themselves are atomic, remember
	the object itself is not locked, and so after ~wp the
	counters that we think are stored in our ~wp could be anything
	and so we could promote without properly incremeting
	the reference ccount
	5. When the sp returned from promote is destroyed, it
	could then destroy the layer, and when our original sp
	from LayerRenderArea is destroyed, we then get the issue
        (which is what we see in the traces).
It's hard to say what this other thread is. Over time we have tried to
move usage of the Layer hierarchy off the Binder threads to achieve
a totally lock-free model. At the moment, I can't find spots in
tip-of-tree which would race with mDrawingParent in this fashion.
Until we are ready to get rid of mStateLock, apply it's usage
consistently with our three rules of locking.

Bug: 220176775
Bug: 223069308
Bug: 223081111
Change-Id: I89c5add585f96b7de1f1b21f76b6ea0c6b0de127
(cherry picked from commit 22ceeaaff9be3e71c5473aeabccdb02705565190)
CRs-Fixed: 3159089

0 files changed, 0 insertions, 0 deletions