Re: [PATCH] Fix pointer tests in error-handling paths

[Dave Gordon <david.s.gordon@intel.com>]

On 22/01/16 13:34, Chris Wilson wrote:
> On Fri, Jan 22, 2016 at 01:17:44PM +0000, Tvrtko Ursulin wrote:
>>
>> On 22/01/16 13:01, Chris Wilson wrote:
>>> On Fri, Jan 22, 2016 at 12:19:32PM +0000, Dave Gordon wrote:
>>>> In the error-handling paths of i915_gem_do_execbuffer() and
>>>> intel_crtc_page_flip(), the local pointer-to-request variables
>>>> were expected to be either valid pointers or NULL. Since
>>>>
>>>>    2682708 drm/i915: simplify allocation of driver-internal requests
>>>>
>>>> they could also be ERR_PTR() values, so the tests need to be
>>>> updated to accommodate this case.
>>>>
>>>> Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>
>>> Quick quiz, name at least testcase that exercised this code?
>>
>> gem_close_race did it for me, but can you explain the weird ERR_PTR
>> of *ffca ? :)
>
> -54
>
> That's odd. gem_close_race should be a mix of ENOENT, EINVAL iirc.
> -Chris

Assuming that's the fault address, it will actually be the sum of the 
errno mistakenly passed to i915_gem_request_cancel(), plus the offset of 
'ringbuf' in the drm_i915_gem_request structure:

void i915_gem_request_cancel(struct drm_i915_gem_request *req)
{
         intel_ring_reserved_space_cancel(req->ringbuf);

         i915_gem_request_unreference(req);
}

As it happens, 'ringbuf' is at offset 0x38 (56), so the errno was -2,
which is the expected error -ENOENT :)

.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx