From: Gregory P. Smith <greg@krypto.org>
Date: Mon, 17 May 2021 07:35:16 +0000 (-0700)
Subject: bpo-44145: Release the GIL around HMAC_Update. (GH-26157)
X-Git-Tag: v3.11.0a1~1097
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=c10392e7ddb3eafbd11e9ffe335c07648426715f;p=thirdparty%2FPython%2Fcpython.git

bpo-44145: Release the GIL around HMAC_Update. (GH-26157)

It was always meant to be released for parallelization.
This now matches the other similar code in the module.

Thanks michaelforney for noticing!
---

diff --git a/Misc/NEWS.d/next/Library/2021-05-16-00-00-38.bpo-44145.ko5SJ7.rst b/Misc/NEWS.d/next/Library/2021-05-16-00-00-38.bpo-44145.ko5SJ7.rst
new file mode 100644
index 000000000000..40222185d506
--- /dev/null
+++ b/Misc/NEWS.d/next/Library/2021-05-16-00-00-38.bpo-44145.ko5SJ7.rst
@@ -0,0 +1,3 @@
+:mod:`hmac` computations were not releasing the GIL while calling the
+OpenSSL ``HMAC_Update`` C API (a new feature in 3.9).  This unintentionally
+prevented parallel computation as other :mod:`hashlib` algorithms support.
diff --git a/Modules/_hashopenssl.c b/Modules/_hashopenssl.c
index e4a288537756..b9e68c05c3ed 100644
--- a/Modules/_hashopenssl.c
+++ b/Modules/_hashopenssl.c
@@ -1496,9 +1496,11 @@ _hmac_update(HMACobject *self, PyObject *obj)
     }
 
     if (self->lock != NULL) {
-        ENTER_HASHLIB(self);
+        Py_BEGIN_ALLOW_THREADS
+        PyThread_acquire_lock(self->lock, 1);
         r = HMAC_Update(self->ctx, (const unsigned char*)view.buf, view.len);
-        LEAVE_HASHLIB(self);
+        PyThread_release_lock(self->lock);
+        Py_END_ALLOW_THREADS
     } else {
         r = HMAC_Update(self->ctx, (const unsigned char*)view.buf, view.len);
     }