[Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Tue Feb 28 15:04:24 UTC 2017


On 28/02/2017 14:52, Michal Wajdeczko wrote:
> On Tue, Feb 28, 2017 at 02:21:23PM +0000, Tvrtko Ursulin wrote:

[snip]

>>> +	GEM_BUG_ON(id < 0 || id >= I915_NUM_ENGINES);
>>
>> The caller of this function iterates 0..ARRAY_SIZE(intel_engines) and also
>> filters with HAS_ENGINE before calling it so not sure this is absolutely
>> needed. Maybe instead:
>>
>> GEM_BUG_ON(id >= ARRAY_SIZE(dev_priv->engine));
>>
>
> With your approach we could drop GEM_BUG_ON completely as with correct
> iteration we should never hit condition id > ARRAY_SIZE.
 >
 > If we could assume that everyone is doing right, then we should never
 > need any asserts at all.

That is not correct. I suggested the function should just check the size 
of the array it is concerned with, rather than assuming how 
I915_NUM_ENGINES relates to the same array.

> Problem is that this function does not know anything about the caller.
> And also it does not know if enums were defined correctly.
> But then it uses these enums as index into two external arrays.
> In my opition we should do our best to catch any inproper usage/definitions.
> If not everywhere, then at least once during build or boot.

Agreed, but intel_engine_setup does not care about the enum so much. It 
cares that it doesn't do out of bounds access to the two arrays. In the 
light of that, GEM_BUG_ON(id >= ARRAY_SIZE(intel_engines) || id >= 
ARRAY_SIZE(dev_priv->engines)) sounds like the most robust solution to me.

Since the function handles failure as well, perhaps we could even 
upgrade that to a WARN_ON and return -EINVAL. Not sure.

Regards,

Tvrtko


More information about the Intel-gfx mailing list