[Mesa-dev] [PATCH 2/2] mesa/fbo: lock ctx->Shared->Mutex when allocating renderbuffers

Brian Paul brianp at vmware.com
Mon Mar 30 08:39:20 PDT 2015


On 03/30/2015 02:25 AM, Martin Peres wrote:
> This mutex is used to make sure the shared context does not change
> while some shared code is looking into it.
>
> Calling BindRenderbufferEXT BindRenderbuffer with a gles context
> would not take the mutex before allocating an entry. Commit a34669b
> then moved out the allocation out of bind_renderbuffer into
> allocate_renderbuffer before using it for the CreateRenderBuffer
> entry point. This thus also made this entry point unsafe.
>
> The issue has been hinted by Illia Mirkin.
>
> Signed-off-by: Martin Peres <martin.peres at linux.intel.com>
> ---
>   src/mesa/main/fbobject.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 5f9a6db..4e85b9c 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -1218,8 +1218,10 @@ allocate_renderbuffer(struct gl_context *ctx, GLuint renderbuffer,
>         return NULL;
>      }
>      assert(newRb->AllocStorage);
> +   mtx_lock(&ctx->Shared->Mutex);
>      _mesa_HashInsert(ctx->Shared->RenderBuffers, renderbuffer, newRb);
>      newRb->RefCount = 1; /* referenced by hash table */
> +   mtx_unlock(&ctx->Shared->Mutex);
>
>      return newRb;
>   }
>

Reviewed-by: Brian Paul <brianp at vmware.com>

There's probably other places where we access ctx->Shared without mutual 
exclusion, but this looks good.



More information about the mesa-dev mailing list