[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