I've pushed this one.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
There is currently no protection against walking a hash (using
_mesa_HashWalk()) and modifying it at the same time, for instance by inserting
or deleting elements. This leads to segfaults in multithreaded code if e.g.
someone calls glTexImage2D (which may have to walk the list of FBOs) while
anothe
On Mon, Nov 07, 2016 at 08:54:13AM +1100, Timothy Arceri wrote:
> The problem is is can happen totally unintentionally. Anyway I've sent
> a couple of patches as a follow-up to your series, one to fix it and
> one to make use of it.
>
> https://patchwork.freedesktop.org/series/14902/
Great, thank
On Sun, 2016-11-06 at 12:16 +0100, Steinar H. Gunderson wrote:
> On Sun, Nov 06, 2016 at 09:35:37AM +1100, Timothy Arceri wrote:
> >
> > Can you please change this line to say something like. With this
> > change
> > we switch to using a recursive mutex, which avoids the deadlock.
>
> Rewording.
On Sun, Nov 06, 2016 at 09:35:37AM +1100, Timothy Arceri wrote:
> Can you please change this line to say something like. With this change
> we switch to using a recursive mutex, which avoids the deadlock.
Rewording.
> I was a little confused. At first I thought it was already using a
> recursive
On Sat, 2016-11-05 at 15:28 +0100, Steinar H. Gunderson wrote:
> There is currently no protection against walking a hash (using
> _mesa_HashWalk()) and modifying it at the same time, for instance by
> inserting
> or deleting elements. This leads to segfaults in multithreaded code
> if e.g.
> someon
There is currently no protection against walking a hash (using
_mesa_HashWalk()) and modifying it at the same time, for instance by inserting
or deleting elements. This leads to segfaults in multithreaded code if e.g.
someone calls glTexImage2D (which may have to walk the list of FBOs) while
anothe
