linux-kernel - Re: [PATCH v3 6/9] dma-buf/fence-array: Add fence deadline support

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]

Date:   Thu, 9 Sep 2021 08:55:38 +0200
From:   Christian König <christian.koenig@....com>
To:     Rob Clark <robdclark@...il.com>, dri-devel@...ts.freedesktop.org,
        linaro-mm-sig@...ts.linaro.org,
        Christian König <ckoenig.leichtzumerken@...il.com>,
        Michel Dänzer <michel@...nzer.net>,
        Pekka Paalanen <ppaalanen@...il.com>,
        Rob Clark <robdclark@...omium.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Gustavo Padovan <gustavo@...ovan.org>,
        "open list:SYNC FILE FRAMEWORK" <linux-media@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 6/9] dma-buf/fence-array: Add fence deadline support

Am 08.09.21 um 20:00 schrieb Daniel Vetter:
> On Fri, Sep 03, 2021 at 11:47:57AM -0700, Rob Clark wrote:
>> From: Rob Clark <robdclark@...omium.org>
>>
>> Signed-off-by: Rob Clark <robdclark@...omium.org>
>> ---
>>   drivers/dma-buf/dma-fence-array.c | 11 +++++++++++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c
>> index d3fbd950be94..8d194b09ee3d 100644
>> --- a/drivers/dma-buf/dma-fence-array.c
>> +++ b/drivers/dma-buf/dma-fence-array.c
>> @@ -119,12 +119,23 @@ static void dma_fence_array_release(struct dma_fence *fence)
>>   	dma_fence_free(fence);
>>   }
>>   
>> +static void dma_fence_array_set_deadline(struct dma_fence *fence,
>> +					 ktime_t deadline)
>> +{
>> +	struct dma_fence_array *array = to_dma_fence_array(fence);
>> +	unsigned i;
>> +
>> +	for (i = 0; i < array->num_fences; ++i)
>> +		dma_fence_set_deadline(array->fences[i], deadline);
> Hm I wonder whether this can go wrong, and whether we need Christian's
> massive fence iterator that I've seen flying around. If you nest these
> things too much it could all go wrong I think. I looked at other users
> which inspect dma_fence_array and none of them have a risk for unbounded
> recursion.

That should work fine or at least doesn't add anything new which could 
go boom.

The dma_fence_array() can't contain other dma_fence_array or 
dma_fence_chain objects or it could end up in a recursion and corrupt 
the kernel stack.

That's a well known limitation for other code paths as well.

So Reviewed-by: Christian König <christian.koenig@....com> for this one.

Regards,
Christian.

>
> Maybe check with Christian.
> -Daniel
>
>
>> +}
>> +
>>   const struct dma_fence_ops dma_fence_array_ops = {
>>   	.get_driver_name = dma_fence_array_get_driver_name,
>>   	.get_timeline_name = dma_fence_array_get_timeline_name,
>>   	.enable_signaling = dma_fence_array_enable_signaling,
>>   	.signaled = dma_fence_array_signaled,
>>   	.release = dma_fence_array_release,
>> +	.set_deadline = dma_fence_array_set_deadline,
>>   };
>>   EXPORT_SYMBOL(dma_fence_array_ops);
>>   
>> -- 
>> 2.31.1
>>