Re: [PATCH] drm/i915: tidy up gen8_init_scratch

[Mika Kuoppala <mika.kuoppala@linux.intel.com>]

Dave Gordon <david.s.gordon@intel.com> writes:

> [ text/plain ]
> On 26/04/16 10:27, Matthew Auld wrote:
>> Use goto teardown path and also ensure we reset any struct members which
>> would otherwise contain an error encoded pointer, and could be mistaken
>> for a valid address.
>>
>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>> ---
>>   drivers/gpu/drm/i915/i915_gem_gtt.c | 36 +++++++++++++++++++++++++-----------
>>   1 file changed, 25 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> index 0d666b3..a723b74 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> @@ -866,31 +866,31 @@ static void gen8_free_page_tables(struct drm_device *dev,
>>   static int gen8_init_scratch(struct i915_address_space *vm)
>>   {
>>   	struct drm_device *dev = vm->dev;
>> +	int ret;
>>
>>   	vm->scratch_page = alloc_scratch_page(dev);
>> -	if (IS_ERR(vm->scratch_page))
>> -		return PTR_ERR(vm->scratch_page);
>> +	if (IS_ERR(vm->scratch_page)) {
>> +		ret = PTR_ERR(vm->scratch_page);
>> +		goto fail_scratch;
>> +	}
>>
>>   	vm->scratch_pt = alloc_pt(dev);
>>   	if (IS_ERR(vm->scratch_pt)) {
>> -		free_scratch_page(dev, vm->scratch_page);
>> -		return PTR_ERR(vm->scratch_pt);
>> +		ret = PTR_ERR(vm->scratch_pt);
>> +		goto fail_pt;
>>   	}
>>
>>   	vm->scratch_pd = alloc_pd(dev);
>>   	if (IS_ERR(vm->scratch_pd)) {
>> -		free_pt(dev, vm->scratch_pt);
>> -		free_scratch_page(dev, vm->scratch_page);
>> -		return PTR_ERR(vm->scratch_pd);
>> +		ret = PTR_ERR(vm->scratch_pd);
>> +		goto fail_pd;
>>   	}
>>
>>   	if (USES_FULL_48BIT_PPGTT(dev)) {
>>   		vm->scratch_pdp = alloc_pdp(dev);
>>   		if (IS_ERR(vm->scratch_pdp)) {
>> -			free_pd(dev, vm->scratch_pd);
>> -			free_pt(dev, vm->scratch_pt);
>> -			free_scratch_page(dev, vm->scratch_page);
>> -			return PTR_ERR(vm->scratch_pdp);
>> +			ret = PTR_ERR(vm->scratch_pdp);
>> +			goto fail_pdp;
>>   		}
>>   	}
>>
>> @@ -900,6 +900,20 @@ static int gen8_init_scratch(struct i915_address_space *vm)
>>   		gen8_initialize_pdp(vm, vm->scratch_pdp);
>>
>>   	return 0;
>> +
>> +fail_pdp:
>> +	vm->scratch_pdp = NULL;
>> +	free_pd(dev, vm->scratch_pd);
>> +fail_pd:
>> +	vm->scratch_pd = NULL;
>> +	free_pt(dev, vm->scratch_pt);
>> +fail_pt:
>> +	vm->scratch_pt = NULL;
>> +	free_scratch_page(dev, vm->scratch_page);
>> +fail_scratch:
>> +	vm->scratch_page = NULL;
>> +
>> +	return ret;
>>   }
>>
>>   static int gen8_ppgtt_notify_vgt(struct i915_hw_ppgtt *ppgtt, bool create)
>
> Well, I agree it's a good idea not to assign non-NULL pointer values to 
> members of an OUT parameter, but perhaps consider a strategy of 
> assigning to a local, checking the result, and storing in the parameter 
> block only after we know that it's a good pointer. Maybe even keep ALL 
> the temporary pointers local and only assign *any* of them when we know 
> we can assign *all* of them and return success. That way there's no 
> cleanup of the result block required in the error path, only freeing of 
> still-local values.

Local would be clean but then it would be burden on the hot path.
Lets just incur the, now useless, writes on the error path.

>
> BTW, as it appears that this function can be called more than once in 
> the lifetime of the driver, do we know that all these pointers will be 
> NULL on entry? Even on the second and subsequent calls?
>

The defensive programming of is good, but in this case we
kzalloc the ppgtt, which contains the struct we are initializing.
If we are unsuccessful, we free the ppgtt. And the function is static
so there are no external users. 

That said, the value of separating the error handling into
a goto teardown is valuable for readability.

Change the goto labels as Joonas suggested and I am
ok with this.

Thanks,
-Mika

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