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

[Jason Ekstrand]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160414/68956a00/attachment.html>