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] [thread-next>] [day] [month] [year] [list]
Message-ID: <c3b173ea-6509-ebbe-b5f9-eeb29f1ce57e@amd.com>
Date:   Tue, 14 Dec 2021 08:09:29 +0100
From:   Christian König <christian.koenig@....com>
To:     Ira Weiny <ira.weiny@...el.com>
Cc:     David Airlie <airlied@...ux.ie>, Daniel Vetter <daniel@...ll.ch>,
        Patrik Jakobsson <patrik.r.jakobsson@...il.com>,
        Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
        linux-arm-msm@...r.kernel.org, intel-gfx@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        amd-gfx@...ts.freedesktop.org
Subject: Re: [PATCH 6/7] drm/amdgpu: Ensure kunmap is called on error

Am 14.12.21 um 04:37 schrieb Ira Weiny:
> On Mon, Dec 13, 2021 at 09:37:32PM +0100, Christian König wrote:
>> Am 11.12.21 um 00:24 schrieb ira.weiny@...el.com:
>>> From: Ira Weiny <ira.weiny@...el.com>
>>>
>>> The default case leaves the buffer object mapped in error.
>>>
>>> Add amdgpu_bo_kunmap() to that case to ensure the mapping is cleaned up.
>> Mhm, good catch. But why do you want to do this in the first place?
> I'm not sure I understand the question.
>
> Any mapping of memory should be paired with an unmapping when no longer needed.
> And this is supported by the call to amdgpu_bo_kunmap() in the other
> non-default cases.
>
> Do you believe the mapping is not needed?

No, the unmapping is not needed here. See the function amdgpu_bo_kmap(), 
it either creates the mapping or return the cached pointer.

A call to amdgpu_bo_kunmap() is only done in a few places where we know 
that the created mapping most likely won't be needed any more. If that's 
not done the mapping is automatically destroyed when the BO is moved or 
freed up.

I mean good bug fix, but you seem to see this as some kind of 
prerequisite to some follow up work converting TTM to use kmap_local() 
which most likely won't work in the first place.

Regards,
Christian.

>
> Ira
>
>> Christian.
>>
>>> Signed-off-by: Ira Weiny <ira.weiny@...el.com>
>>>
>>> ---
>>> NOTE: It seems like this function could use a fair bit of refactoring
>>> but this is the easiest way to fix the actual bug.
>>> ---
>>>    drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 1 +
>>>    1 file changed, 1 insertion(+)
>>> nice
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
>>> index 6f8de11a17f1..b3ffd0f6b35f 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
>>> @@ -889,6 +889,7 @@ static int amdgpu_uvd_cs_msg(struct amdgpu_uvd_cs_ctx *ctx,
>>>    		return 0;
>>>    	default:
>>> +		amdgpu_bo_kunmap(bo);
>>>    		DRM_ERROR("Illegal UVD message type (%d)!\n", msg_type);
>>>    	}

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ