[Mesa-dev] [PATCH] util: Fix race condition on libgcrypt initialization

Eduardo Lima Mitev elima at igalia.com
Fri Apr 15 07:15:07 UTC 2016


On 04/13/2016 12:41 AM, Matt Turner wrote:
> On Tue, Apr 12, 2016 at 3:10 PM, Mark Janes <mark.a.janes at intel.com> wrote:
>> Fixes intermittent Vulkan CTS failures within the test groups:
>> dEQP-VK.api.object_management.multithreaded_per_thread_device
>> dEQP-VK.api.object_management.multithreaded_per_thread_resources
>> dEQP-VK.api.object_management.multithreaded_shared_resources
>>
>> Signed-off-by: Mark Janes <mark.a.janes at intel.com>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94904
> 
> Have you seen https://gnupg.org/documentation/manuals/gcrypt/Multi_002dThreading.html#Multi_002dThreading
> ?
> 
> I feel pretty uncertain that the patch as it is would be sufficient in
> general, but maybe it's okay since we're just using libgcrypt for
> SHA1?

Just wondering, if we use libgcrypt for SHA1 only, wouldn't be better to
ship the implementation ourselves (taking it from libnettle or other
cleaner code), and remove the dependency altogether? The SHA1
implementation is not specially big or complex, or expected to change
much in the future.

Eduardo


More information about the mesa-dev mailing list