lkml.org 
[lkml]   [2017]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] drm/amd/amdgpu: get rid of else branch
From
Date
Am 04.05.2017 um 14:57 schrieb Nikola Pajkovsky:
> Christian König <christian.koenig@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.

\
 
 \ /
  Last update: 2017-05-04 15:19    [W:0.351 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site