Yeah that matches my expectations. And yes we need to make sure not to completely overflow such arrays.
Christian. On 3/12/26 21:43, Marek Olšák wrote: > I have just gathered real data on this and the result is surprising. > Viewperf 13, Viewperf 2020, Unigine benchmarks, and others have been > used to gather BO list data. > > The maximum number of BOs that has been observed in the CS ioctl for > radeonsi is 283, even though the actual number of OpenGL BOs can be on > the order of 50k. That's thanks to the slab allocator in the Mesa > amdgpu winsys. > > RADV uses VM_ALWAYS_VALID by default currently. radeonsi could also > start using it if the kernel memory management behaves optimally. > > Old Mesa drivers might use more BOs, especially RADV which doesn't > have a slab allocator. > > Some limit may also be needed for lists of sync objects in all our > ioctls and all arrays in general. > > Marek > > On Thu, Mar 12, 2026 at 1:59 PM Christian König > <[email protected]> wrote: >> >> On 3/12/26 18:44, Alex Deucher wrote: >>> + Marek, >>> >>> This was the feedback from Marek the last time this was brought up: >>> >>> "USHRT_MAX seems too low. Traces for workstation apps create 20-30k >>> BOs, which is not very far from the limit. RADV doesn't suballocate >>> BOs. Neither GL nor VK has a ilmit on the number of BOs that can be >>> created. The hypothetical maximum number of BOs that can be allocated >>> on a GPU with 32GB of addressable memory is 8 million." >>> >>> Does 128K sound more reasonable? >> >> I think so, yes. Event 64k seems reasonable large to me considering that >> only BOs which are not per VM need to be in the list. >> >> E.g. RADV barely uses this feature as far as I know. >> >> Regards, >> Christian. >> >>> >>> Alex >>> On Thu, Mar 12, 2026 at 6:13 AM Jesse.Zhang <[email protected]> wrote: >>>> >>>> Userspace can pass an arbitrary number of BO list entries via the >>>> bo_number field. Although the previous multiplication overflow check >>>> prevents out-of-bounds allocation, a large number of entries could still >>>> cause excessive memory allocation (up to potentially gigabytes) and >>>> unnecessarily long list processing times. >>>> >>>> Introduce a hard limit of 128k entries per BO list, which is more than >>>> sufficient for any realistic use case (e.g., a single list containing all >>>> buffers in a large scene). This prevents memory exhaustion attacks and >>>> ensures predictable performance. >>>> >>>> Return -EINVAL if the requested entry count exceeds the limit >>>> >>>> Suggested-by: Christian König <[email protected]> >>>> Signed-off-by: Jesse Zhang <[email protected]> >>>> --- >>>> drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 4 ++++ >>>> 1 file changed, 4 insertions(+) >>>> >>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c >>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c >>>> index 87ec46c56a6e..3270ea50bdc7 100644 >>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c >>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c >>>> @@ -36,6 +36,7 @@ >>>> >>>> #define AMDGPU_BO_LIST_MAX_PRIORITY 32u >>>> #define AMDGPU_BO_LIST_NUM_BUCKETS (AMDGPU_BO_LIST_MAX_PRIORITY + 1) >>>> +#define AMDGPU_BO_LIST_MAX_ENTRIES (128 * 1024) >>>> >>>> static void amdgpu_bo_list_free_rcu(struct rcu_head *rcu) >>>> { >>>> @@ -188,6 +189,9 @@ int amdgpu_bo_create_list_entry_array(struct >>>> drm_amdgpu_bo_list_in *in, >>>> const uint32_t bo_number = in->bo_number; >>>> struct drm_amdgpu_bo_list_entry *info; >>>> >>>> + if (bo_number > AMDGPU_BO_LIST_MAX_ENTRIES) >>>> + return -EINVAL; >>>> + >>>> /* copy the handle array from userspace to a kernel buffer */ >>>> if (likely(info_size == bo_info_size)) { >>>> info = vmemdup_array_user(uptr, bo_number, info_size); >>>> -- >>>> 2.49.0 >>>> >>
