linux-kernel - Re: amdgpu: Corrupted video on 32 bit systems (possible fix)

Open Source and information security mailing list archives

Message-ID: <d45d5242-5c42-1ac7-d850-dae49804ec09@vodafone.de>
Date:   Fri, 20 Jan 2017 10:11:41 +0100
From:   Christian König <deathsimple@...afone.de>
To:     Nils Holland <nholland@...ys.org>,
        Michel Dänzer <michel@...nzer.net>
Cc:     amd-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org
Subject: Re: amdgpu: Corrupted video on 32 bit systems (possible fix)

Am 20.01.2017 um 08:44 schrieb Nils Holland:
> On Fri, Jan 20, 2017 at 11:47:53AM +0900, Michel Dänzer wrote:
>> On 20/01/17 04:35 AM, Nils Holland wrote:
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c	2016-12-11 20:17:54.000000000 +0100
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c	2017-01-19 15:38:56.972034489 +0100
>>> @@ -372,6 +372,10 @@
>>>   	if (!drm_arch_can_wc_memory())
>>>   		bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC;
>>>   
>>> +	#ifdef CONFIG_X86_32
>>> +		bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC;
>>> +	#endif
>>> +
>>>   	amdgpu_fill_placement_to_bo(bo, placement);
>>>   	/* Kernel allocation are uninterruptible */
>>>   	r = ttm_bo_init(&adev->mman.bdev, &bo->tbo, size, type,
>> The corresponding code in the radeon driver has changed quite a bit
>> since this original fix. It would be better to bring the amdgpu code in
>> line with the current radeon code.
>>
>>
>>> With this patch, the amdgpu driver works fine for me on my 32 bit
>>> kernel: All graphics output looks the way it's supposed to, even with
>>> full acceleration enabled - great!
>>>
>>> I'd suggest that it might be a good idea to put to apply the above
>>> patch or something similar to the official sources.
>> Indeed. Do you want to create a proper patch and submit it to the
>> amd-gfx mailing list for review? See Documentation/SubmittingPatches for
>> more information.
> Sounds like a good idea! I was a bit heasitant because, to be honest,
> I'm not at all an expert about the code in question and basically only
> saw how you fixed the issue in radeon and thought: "Well, let's see if
> I can do the same thing in amdgpu and if so, if it helps there, too".
> ;-)

Well first of all thanks for testing this and pointing into the correct 
direction how to fix the issue.

>
> However, since you've said that a 32 bit fix in amdgpu generally seems
> like a good idea, I would indeed use a little time on the weekend to
> get a proper patch ready and submit it for review. Even if the "no wc
> for x86_32" part is probably the only thing it'll contain - more of
> "bringing the amdgpu code in line with the current radeon code" might,
> for the time being, be beyond my capabilities, at least if we assume
> that the code should stay in a sane and working condition. ;-)

The amdgpu code is a successor of the radeon code, we just forked it of 
to avoid regressing radeon while working on new stuff (and radeon just 
became way to big to handle).

Unfortunately that fork happened before the final fix in radeon for 
32bit systems landed. I think it's just the #if condition which changed 
on radeon, e.g. instead of always disabling it on 32bit X86 we do so 
when the feature needed for USWC isn't enabled on the architecture in 
general IIRC.

Shouldn't be to much of an issue to port the current status over to amdgpu.

Regards,
Christian.

>
> Thanks and greetings
> Nils
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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