Re: [PATCH v2] drm/syncobj: Limit the number of handles and use kvmalloc for user-sized arrays

[Yu, Fei]

From: Fei Yu <fei.yu@xxxxxxxxx>

On 04/11/2026 10:27, Tvrtko Ursulin wrote:
> On 04/11/2026 09:44, Christian König wrote:
>> On 11/4/26 04:09, Yu, Fei wrote:
>>> +#define DRM_SYNCOBJ_MAX_HANDLES        (INT_MAX / sizeof(struct syncobj_wait_entry))
>>
>> I really wonder if we should put that into the uAPI files?
>>
>> Not that userspace is potentially using it, but this is part of the uAPI
>> and makes sense for documentation purposes.

I thought about that, but I'd prefer to keep it kernel internal, at
least for this fix:

 - The value is derived from the size of a kernel internal struct and
   from the kvmalloc() size limit, so it is not the same on 32-bit and
   64-bit. To put it in drm.h I would have to replace it with a fixed
   number, and that number becomes ABI. We could not easily raise or
   lower it later.

 - Tvrtko's series below avoids most of these allocations. Once that
   lands, the right limit may be different, and an internal define is
   easier to change.

 - The patch has a Fixes tag, and keeping it out of the uAPI header
   keeps the stable backport small.

For documentation, I could send a follow-up that adds a sentence to the
uAPI struct comments, saying that count_handles above an implementation
defined limit is rejected with -EINVAL. That documents the behavior
without fixing a number. Would that work for you?

>> That kvmalloc_array() + the following copy_from_user should probably be
>> replaced by using vmemdup_array_user(). But that should of course be a
>> separate patch.
>
> Btw I tried to do that some time ago:
>
> https://lore.kernel.org/dri-devel/20251106132645.28208-1-tvrtko.ursulin@xxxxxxxxxx/#t
>
> I have as local, more recent version which applies, but apparently never
> sent it.
>
> Interesting part should also be the other patches from the above linked
> series which avoid allocations altogether for the vast majority of cases.
>
> If there is interest I can re-base and re-send after this is merged.

Thanks, I wasn't aware of that series. I'll leave the
vmemdup_array_user() and points array cleanups to it, so we don't
duplicate work. Happy to test it once this fix is in.

Regards,
Fei