linux-kernel - Re: [PATCH 9/9] drm/panfrost: Explicitly clean up panfrost fence

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: <51315b7a-02a7-415f-b69b-3a7919e921f6@amd.com>
Date: Thu, 17 Oct 2024 11:27:08 +0200
From: Christian König <christian.koenig@....com>
To: Adrián Larumbe <adrian.larumbe@...labora.com>
Cc: Boris Brezillon <boris.brezillon@...labora.com>,
 Rob Herring <robh@...nel.org>, Steven Price <steven.price@....com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Philipp Zabel <p.zabel@...gutronix.de>,
 Sumit Semwal <sumit.semwal@...aro.org>, kernel@...labora.com,
 dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 linux-media@...r.kernel.org, linaro-mm-sig@...ts.linaro.org
Subject: Re: [PATCH 9/9] drm/panfrost: Explicitly clean up panfrost fence

Am 16.10.24 um 18:43 schrieb Adrián Larumbe:
> On 16.10.2024 15:12, Christian König wrote:
>> Am 15.10.24 um 01:31 schrieb Adrián Larumbe:
>>> Doesn't make any functional difference because generic dma_fence is the
>>> first panfrost_fence structure member, but I guess it doesn't hurt either.
>> As discussed with Sima we want to push into the exactly opposite direction
>> because that requires that the panfrost module stays loaded as long as fences
>> are around.
> Does that mean in future commits the struct dma_fence_ops' .release pointer will be
> done with altogether?

Yes, exactly that's the idea.

As a first step I'm preparing patches right now to enforce using kmalloc 
instead of driver brewed approaches for dma_fence handling.

Regards,
Christian.

>
>> So clearly a NAK to this one here. Rather document on the structure that the
>> dma_fence structure must be the first member.
>>
>> Regards,
>> Christian.
>>
>>> Signed-off-by: Adrián Larumbe <adrian.larumbe@...labora.com>
>>> ---
>>>    drivers/gpu/drm/panfrost/panfrost_job.c | 6 ++++++
>>>    1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c
>>> index 5d83c6a148ec..fa219f719bdc 100644
>>> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
>>> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
>>> @@ -85,9 +85,15 @@ static const char *panfrost_fence_get_timeline_name(struct dma_fence *fence)
>>>    	}
>>>    }
>>> +static void panfrost_fence_release(struct dma_fence *fence)
>>> +{
>>> +	kfree(to_panfrost_fence(fence));
>>> +}
>>> +
>>>    static const struct dma_fence_ops panfrost_fence_ops = {
>>>    	.get_driver_name = panfrost_fence_get_driver_name,
>>>    	.get_timeline_name = panfrost_fence_get_timeline_name,
>>> +	.release = panfrost_fence_release,
>>>    };
>>>    static struct dma_fence *panfrost_fence_create(struct panfrost_device *pfdev, int js_num)