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

[Mark Janes]

Jason Ekstrand <jason at jlekstrand.net> writes:

> On Tue, Apr 12, 2016 at 3:51 PM, Jason Ekstrand <jason at jlekstrand.net>
> wrote:
>
>>
>> On Apr 12, 2016 3:41 PM, "Matt Turner" <mattst88 at gmail.com> 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?
>>
>> Ugh... It should be *mostly* safe as mesa only uses gcrypt for it's sha1
>> implementation.  However, if something uses GL and uses libgcrypt for
>> something else, we may have a large, hard-to-debug problem.
>>
>> Not sure how dire we think it is. Would it be better to remove the gcrypt
>> implementation in light of this?
>>
> I think this patch is certainly *better* than what we had before.  In light
> of the issues, we may want to remove gcrypt support but that can be a
> separate patch.  Mark, do you mind pushing it to mesa master?

I agree that the patch is an improvement.  The caveats listed in the
documentation are troubling, but it does seem that the sha1
implementation relies on the caller to pass in context.  Other parts of
the library certainly rely on internal state that is not thread-safe.

I pushed the patch to the vulkan branch, because that is where the bug
manifested.  I'll push it to master as well.

-Mark