[RFC] drm/amd/amdgpu: get rid of else branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 04.05.2017 um 14:57 schrieb Nikola Pajkovsky:
> Christian König <christian.koenig at amd.com> writes:
>
>> Am 27.04.2017 um 18:17 schrieb Nikola Pajkovsky:
>>> This is super simple elimination of else branch and I should
>>> probably even use unlikely in
>>>
>>>    	if (ring->count_dw < count_dw) {
>>>
>>> However, amdgpu_ring_write() has similar if condition, but does not
>>> return after DRM_ERROR and it looks suspicious. On error, we still
>>> adding v to ring and keeping count_dw-- below zero.
>>>
>>> 	if (ring->count_dw <= 0)
>>> 		DRM_ERROR("amdgpu: writing more dwords to the ring than expected!\n");
>>> 	ring->ring[ring->wptr++] = v;
>>> 	ring->wptr &= ring->ptr_mask;
>>> 	ring->count_dw--;
>>>
>>> I can obviously be totaly wrong. Hmm?
>> That's just choosing the lesser evil.
>>
>> When we write more DW to the ring than expected it is possible (but
>> not likely) that we override stuff on the ring buffer which is still
>> executed by the command processor leading to a possible CP crash.
>>
>> But when we completely drop the write the commands in the ring buffer
>> will certainly be invalid and so the CP will certainly crash sooner or
>> later.
> Instead of choosing the lesser evil, is there good way to design ring
> buffer right way?

It is designed the right way.

See this only happens when a developer increases the number of dw 
written, but forgets to reserve ring buffer space before starting the write.

When the function recognizes that something is wrong it is to late to 
actually reserve more space, so the only option left is printing a 
message for the dev to fix the code.


>> Please add the unlikely() as well and then send out the patch with a
>> signed-of-by line and I will be happy to push it into our upstream
>> branch.
> Proper patch has been sent.

Seen and reviewed, thanks for the help.

Christian.



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux