(This is a merge of http://go/wvgerrit/71324)
This patch increases the granularity of the locking in CryptoSession
without substantially changing its locking semantics. Where before
there was a single |crypto_lock_| performing multiple duties, now
there are three locks:
1) |static_field_lock_|, which is used when needing to access the
non-atomic static member fields of CryptoSession.
2) |oem_crypto_lock_|, which is used when needing to call into
OEMCrypto.
3) |factory_lock_|, used only by the functions that interact with the
CryptoSession factory.
All the code in CryptoSession has been updated to use these locks. It
has also been updated to only hold them for the minimal amount of time
necessary, as opposed to holding them for a whole function. This should
help some with the ability of CryptoSession calls to happen
concurrently. To assist in taking locks in a consistent manner, two
helper functions, |WithStaticFieldLock()| and |WithOecLock()| have been
added. Also, for the very common case of reading |initialized_|, the
accessor |IsInitialized()| will read the value safely.
While changing all the code to lock differently, I found that some
places in CryptoSession were *not* locking before accessing static state
or calling into OEMCrypto. I have made these callsites consistent with
the rest of CryptoSession.
As a result of taking locks for only the minimum time necessary, it is
no longer necessary for functions to make assumptions about whether the
lock will already be held before they are called. Locks should not be
held while calling helper functions, and code should always take a lock
for the brief time it is necessary to do so.
In tests, including the concurrent unit tests coming in the following
patch, this code did not perform substantially better or worse than the
code that preceded it, but the hope is that it will experience less
contention on devices that are more resource-constrained than my
desktop, such as older game consoles.
This patch appears to address some real threading issues. Hopefully, it
will also make it easier to maintain soundness in the future and to
reason about when code in CryptoSession needs to take a lock.
This is the first step to implementing the "Finer-Grained Locking in
CryptoSession" specification. A future patch will make some of these
locks reader-writer locks, to allow even greater parallelism.
Bug: 70889998
Bug: 118584039
Bug: 123319961
Test: CE CDM Unit Tests
Test: Android Unit Tests
Test: GTS
Test: Play Movies
Test: Netflix
Change-Id: I346c04a5d9875723db54af33ee91772bf49ca12f
7e97ba4383