[PATCH 1/3] dma-buf/dma-fence_array: use kvzalloc
Tvrtko Ursulin
tursulin at ursulin.net
Thu Nov 7 11:29:27 UTC 2024
On 28/10/2024 10:34, Christian König wrote:
> Am 25.10.24 um 11:05 schrieb Tvrtko Ursulin:
>>
>> On 25/10/2024 09:59, Tvrtko Ursulin wrote:
>>>
>>> On 24/10/2024 13:41, Christian König wrote:
>>>> Reports indicates that some userspace applications try to merge more
>>>> than
>>>> 80k of fences into a single dma_fence_array leading to a warning from
>>>> kzalloc() that the requested size becomes to big.
>>>>
>>>> While that is clearly an userspace bug we should probably handle
>>>> that case
>>>> gracefully in the kernel.
>>>>
>>>> So we can either reject requests to merge more than a reasonable
>>>> amount of
>>>> fences (64k maybe?) or we can start to use kvzalloc() instead of
>>>> kzalloc().
>>>> This patch here does the later.
>>>
>>> Rejecting would potentially be safer, otherwise there is a path for
>>> userspace to trigger a warn in kvmalloc_node (see 0829b5bcdd3b
>>> ("drm/i915: 2 GiB of relocations ought to be enough for anybody*"))
>>> and spam dmesg at will.
>>
>> Actually that is a WARN_ON_*ONCE* there so maybe not so critical to
>> invent a limit. Up for discussion I suppose.
>>
>> Regards,
>>
>> Tvrtko
>>
>>>
>>> Question is what limit to set...
>
> That's one of the reasons why I opted for kvzalloc() initially.
I didn't get that, what was the reason? To not have to invent an
arbitrary limit?
> I mean we could use some nice round number like 65536, but that would be
> totally arbitrary.
Yeah.. Set an arbitrary limit so a warning in __kvmalloc_node_noprof()
is avoided? Or pass __GFP_NOWARN?
> Any comments on the other two patches? I need to get them upstream.
Will look into them shortly.
Regards,
Tvrtko
> Thanks,
> Christian.
>
>>>
>>> Regards,
>>>
>>> Tvrtko
>>>
>>>> Signed-off-by: Christian König <christian.koenig at amd.com>
>>>> CC: stable at vger.kernel.org
>>>> ---
>>>> drivers/dma-buf/dma-fence-array.c | 6 +++---
>>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/dma-buf/dma-fence-array.c
>>>> b/drivers/dma-buf/dma-fence-array.c
>>>> index 8a08ffde31e7..46ac42bcfac0 100644
>>>> --- a/drivers/dma-buf/dma-fence-array.c
>>>> +++ b/drivers/dma-buf/dma-fence-array.c
>>>> @@ -119,8 +119,8 @@ static void dma_fence_array_release(struct
>>>> dma_fence *fence)
>>>> for (i = 0; i < array->num_fences; ++i)
>>>> dma_fence_put(array->fences[i]);
>>>> - kfree(array->fences);
>>>> - dma_fence_free(fence);
>>>> + kvfree(array->fences);
>>>> + kvfree_rcu(fence, rcu);
>>>> }
>>>> static void dma_fence_array_set_deadline(struct dma_fence *fence,
>>>> @@ -153,7 +153,7 @@ struct dma_fence_array
>>>> *dma_fence_array_alloc(int num_fences)
>>>> {
>>>> struct dma_fence_array *array;
>>>> - return kzalloc(struct_size(array, callbacks, num_fences),
>>>> GFP_KERNEL);
>>>> + return kvzalloc(struct_size(array, callbacks, num_fences),
>>>> GFP_KERNEL);
>>>> }
>>>> EXPORT_SYMBOL(dma_fence_array_alloc);
>
More information about the dri-devel
mailing list