7e97ba4383
(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