linux-kernel - Re: [RFC] drm/amd/amdgpu: get rid of else branch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 4 May 2017 15:19:01 +0200
From:   Christian König <christian.koenig@....com>
To:     Nikola Pajkovsky <npajkovsky@...e.cz>
CC:     <linux-kernel@...r.kernel.org>,
        Alex Deucher <alexander.deucher@....com>,
        David Airlie <airlied@...ux.ie>,
        <dri-devel@...ts.freedesktop.org>, <amd-gfx@...ts.freedesktop.org>
Subject: Re: [RFC] drm/amd/amdgpu: get rid of else branch

Am 04.05.2017 um 14:57 schrieb Nikola Pajkovsky:
> Christian König <christian.koenig@....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.