mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Nikola Pajkovsky <npajkovsky@suse.cz>
Cc: <linux-kernel@vger.kernel.org>,
	Alex Deucher <alexander.deucher@amd.com>,
	David Airlie <airlied@linux.ie>,
	<dri-devel@lists.freedesktop.org>,
	<amd-gfx@lists.freedesktop.org>
Subject: Re: [RFC] drm/amd/amdgpu: get rid of else branch
Date: Thu, 4 May 2017 15:19:01 +0200	[thread overview]
Message-ID: <6b631d8f-73de-5a3d-7cf8-a7bb3565e71a@amd.com> (raw)
In-Reply-To: <87efw47pah.fsf@suse.cz>

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.

      reply	other threads:[~2017-05-04 13:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-27 16:17 Nikola Pajkovsky
2017-04-28  8:30 ` Christian König
2017-05-04 12:57   ` Nikola Pajkovsky
2017-05-04 13:19     ` Christian König [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6b631d8f-73de-5a3d-7cf8-a7bb3565e71a@amd.com \
    --to=christian.koenig@amd.com \
    --cc=airlied@linux.ie \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npajkovsky@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome