Clarify rand locking comment.
This was specific to some old software on the test machine. Shrinking
the critical section to not cover getrandom is probably worthwhile
anyway though, so keep it around but make the comment less scary.
Change-Id: I8c17b6688ae93f6aef5d89c252900985d9e7bb52
Reviewed-on: https://boringssl-review.googlesource.com/16992
Reviewed-by: Adam Langley <agl@google.com>
diff --git a/crypto/fipsmodule/rand/rand.c b/crypto/fipsmodule/rand/rand.c
index a99baf8..eb99f72 100644
--- a/crypto/fipsmodule/rand/rand.c
+++ b/crypto/fipsmodule/rand/rand.c
@@ -305,9 +305,9 @@
* |rand_thread_state_clear_all|.
*
* This lock must be taken after any calls to |CRYPTO_sysrand| to avoid a
- * bug on ppc64le. glibc may implement locks by wrapping the critical
- * section in a hardware transaction. This appears to sometimes break
- * |getrandom|. */
+ * bug on ppc64le. glibc may implement pthread locks by wrapping user code
+ * in a hardware transaction, but, on some older versions of glibc and the
+ * kernel, syscalls made with |syscall| did not abort the transaction. */
CRYPTO_STATIC_MUTEX_lock_read(thread_states_list_lock_bss_get());
#endif
if (!CTR_DRBG_reseed(&state->drbg, seed, NULL, 0)) {
