On Mon, 2017-08-21 at 12:05 +0100, Emil Velikov wrote:
> > On 21 August 2017 at 11:57, Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> wrote:
> > If drmPrimeFDToHandle fails in etna_bo_from_dmabuf, the function must
> > not return with the table_lock mutex held. There is no reason to call
> > drmPrimeFDToHandle under that lock, so just take the lock after trying
> > to obtain the handle.
> >
> > Based on ceb70a6b1015 ("freedreno: prevent deadlock in error path").
> >
>
> Can you skim through cf40cf05a4d7f3945d534790e7768a048adc3ab0 and it's
> commit message.
>
> Doesn't a similar issue apply here as well?
I think you are right. If fd_bo_del is called at the same time as
fd_bo_from_dmabuf with an fd that maps to the same BO, bo_del may call
GEM_CLOSE with the same handle that drmPrimeFDToHandle just returned,
possibly invalidating it before fd_bo_from_dmabuf can take the lock.
regards
Philipp
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
