Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib: Fix intel_get_current_physical_engine() iterator

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 03/06/2019 12:19, Petri Latvala wrote:
> On Mon, Jun 03, 2019 at 11:39:25AM +0100, Tvrtko Ursulin wrote:
>>
>> On 03/06/2019 11:32, Petri Latvala wrote:
>>> On Mon, Jun 03, 2019 at 11:19:48AM +0100, Tvrtko Ursulin wrote:
>>>>
>>>> On 29/05/2019 14:24, Chris Wilson wrote:
>>>>> If we run out of engines, intel_get_current_physical_engine() degrades
>>>>> into an infinite loop as although it advanced the iterator, it did not
>>>>> update its local engine pointer.
>>>>
>>>> We had one infinite loop in there already.. AFAIR it was on one engine
>>>> platforms. Does the new incarnation happen actually via the
>>>> __for_each_physical_engine iterator or perhaps only when calling
>>>> intel_get_current_physical_engine after loop end? Why it wasn't seen in
>>>> testing?
>>>
>>>
>>> The new incarnation happens with a wedged GPU. That's a case that's
>>> hard to come by in testing.
>>
>> 1.
>> Colour me confused. :) How does a wedged GPU affect this loop?
> 
> Wedging could be a red herring, but regardless the GPU was in a funky
> state.
> 
> An easy reproduction method is just
> 
> #  ./perf_pmu
> 
> (as normal user, not root!)

See it now, so the problem is code is not capable of handling zero 
engines (which it happens if no access to drm master like in your example).

As such, Chris' patch looks okay to me.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

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