Author gwk
Recipients gwk
Date 2019-04-03.15:04:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1554303875.24.0.336244422636.issue36519@roundup.psfhosted.org>
In-reply-to
Content
I was browsing the Blake2b module implementation in master and noticed two subtle issues in blake2b_impl.c. There are two places where the GIL gets released; both of them appear flawed.

py_blake2b_new_impl, line 221. The ALLOW_THREADS block fails to acquire/release self->lock.

_blake2_blake2b_update, line 279. The lock is lazily allocated correctly on line 279. However the test on 282 that chooses to release the GIL or not fails to take into account the length test. This means that once a large block is fed to `update`, then every call to update will release the GIL, even if it is a single byte.

It should look something more like this:
```
bool should_allow_threads = (buf.len >= HASHLIB_GIL_MINSIZE);
if (should_allow_threads && self->lock == NULL)
  self->lock = PyThread_allocate_lock();
if (should_allow_threads && self->lock != NULL) { ... }
else { ... }
```

This respects the size criterion, and also protects against the case where the lock allocation fails.
History
Date User Action Args
2019-04-03 15:04:35gwksetrecipients: + gwk
2019-04-03 15:04:35gwksetmessageid: <1554303875.24.0.336244422636.issue36519@roundup.psfhosted.org>
2019-04-03 15:04:35gwklinkissue36519 messages
2019-04-03 15:04:34gwkcreate