[Intel-gfx] [PATCH] drm/i915/mtl: Check full IP version when applying hw steering semaphore

[Tvrtko Ursulin]

On 05/12/2022 16:27, Matt Roper wrote:
> On Mon, Dec 05, 2022 at 12:50:40PM +0000, Tvrtko Ursulin wrote:
>>
>> On 02/12/2022 22:49, Rodrigo Vivi wrote:
>>> On Fri, Dec 02, 2022 at 02:35:28PM -0800, Matt Roper wrote:
>>>> When determining whether the platform has a hardware-level steering
>>>> semaphore (i.e., MTL and beyond), we need to use GRAPHICS_VER_FULL() to
>>>> compare the full version rather than just the major version number
>>>> returned by GRAPHICS_VER().
>>>>
>>>> Reported-by: kernel test robot <lkp at intel.com>
>>>> Fixes: 3100240bf846 ("drm/i915/mtl: Add hardware-level lock for steering")
>>>> Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan at intel.com>
>>>> Signed-off-by: Matt Roper <matthew.d.roper at intel.com>
>>>
>>> Reviewed-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
>>>> ---
>>>>    drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 4 ++--
>>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
>>>> index 087e4ac5b68d..41a237509dcf 100644
>>>> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
>>>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
>>>> @@ -367,7 +367,7 @@ void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long *flags)
>>>>    	 * driver threads, but also with hardware/firmware agents.  A dedicated
>>>>    	 * locking register is used.
>>>>    	 */
>>>> -	if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
>>>> +	if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
>>
>> Ouch, tricky class of bugs... Anyone has an idea how to maybe coerce the compiler into spotting them for us, cheaply?
> 
> I believe clang can already notice these problems with
> Wtautological-constant-out-of-range-compare (which is how the kernel
> test robot finds them):
> 
> 	>> drivers/gpu/drm/i915/gt/intel_gt_mcr.c:370:29: warning: result of comparison of constant 3142 with expression of type 'u8' (aka 'unsigned char')
> 	+is always false [-Wtautological-constant-out-of-range-compare]
> 		   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
> 		       ~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~
> 	   drivers/gpu/drm/i915/gt/intel_gt_mcr.c:410:29: warning: result of comparison of constant 3142 with expression of type 'u8' (aka 'unsigned char')
> 	+is always false [-Wtautological-constant-out-of-range-compare]
> 		   if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
> 		       ~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~
> 	   2 warnings generated.

Hah.. curios how IS_ENABLED then works on clang builds. Maybe it has 
some special handling for that flavour of "always false".

> Unfortunately gcc doesn't seem to have anything equivalent as far as I
> can see.
> 
>>
>> This one is undefined behaviour I think so not good:
>>
>> -#define IP_VER(ver, rel)               ((ver) << 8 | (rel))
>> +typedef void * i915_full_ver_t;
>> +
>> +#define IP_VER(ver, rel) (i915_full_ver_t)(unsigned long)((ver) << 8 | (rel))
> 
> Hmm, so by casting it into a pointer, you're hoping to trigger a
> "comparison of pointer and integer without cast" warning on misuse?
> That's a good idea, but as you noted, the C99 spec says comparison of
> pointers is only guaranteed to work if both are pointers into the same
> structure/array, otherwise the results are technically undefined.

"error: comparison between pointer and integer" - it works, but yes it 
is undefined. Only == and != are allowed on random void * pointers.

Since you say clang builds report the problem we are good I guess.

Regards,

Tvrtko