On Wed, Aug 7, 2013 at 12:30 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > On Wed, Aug 07, 2013 at 12:09:33PM +0200, Daniel Vetter wrote: >> It's unclear whether ->map is allowed to fail with -EINTR, but >> looking at current callers it's pretty clear that they don't >> expect this to happen. So use a blocking mutex_lock call. Since >> we don't wait for the gpu in our ->map callback the lack of the >> gpu hang checks doesn't matter. >> >> Furthermore the goal is to eventually have per dma-buf locking done >> by callers with ww mutexes, so this will then be removed. >> >> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> >> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > Ugh, who can't handle EINTR here but can handle all the other errors? Ok, I've re-read the code and I think callers can actually cope. I'm just freaked out that we don't have test coverage for these case, but that should be a moot point once all the locking is converted over to ww mutexes. So I'll drop this patch here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
