On Tue, Mar 25, 2014 at 09:07:00AM +0100, Daniel Vetter wrote: > On Tue, Mar 25, 2014 at 9:03 AM, Chris Wilson <ch...@chris-wilson.co.uk> > wrote: > > If we try to execute on a known ring, but it has failed to be > > initialised correctly, report that the GPU is hung rather than the > > command invalid. This leaves us reporting EINVAL only if the user > > requests execution on a ring that is not supported by the device. > > > > This should prevent UXA from getting stuck in a null render loop after a > > failed resume. > > > > Reported-by: Jiri Kosina <ji...@jikos.cz> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=76554 > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > > Feels a bit like duct-tape ... Shouldn't we instead stop tearing down > ringbuffer structures over suspend/resume? And maybe the same for init > with your patch applied.
Even if we did, we would still end up with g45 failing to restart the ring at random, so we need some w/a. > Or we simply check for wedged first thing in execbuf ... See the first 2 patches ;-) The first is actually essential as we have no other guard against writing into the non-existent ring. I thought about doing that. However, I prefer doing arg validation first i.e. get all (or as much as is feasible) of the EINVAL checks out of the way so that we avoid touching hardware or leaking any information to a malicious client. The problem in this case is where is not actually an invalid arg. Note that we will detect the EIO later before touching hardware (so long as the first two patches are in place). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
