* [PATCH v2] drm/amdgpu: Limit BO list entry count to prevent resource exhaustion
@ 2026-03-12 10:13 Jesse.Zhang
2026-03-12 10:14 ` Christian König
2026-03-12 17:44 ` Alex Deucher
0 siblings, 2 replies; 6+ messages in thread
From: Jesse.Zhang @ 2026-03-12 10:13 UTC (permalink / raw)
To: amd-gfx; +Cc: Alexander.Deucher, Christian Koenig, Jesse.Zhang, Jesse Zhang
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 <christian.koenig@amd.com>
Signed-off-by: Jesse Zhang <jesse.zhang@amd.com>
---
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
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] drm/amdgpu: Limit BO list entry count to prevent resource exhaustion
2026-03-12 10:13 [PATCH v2] drm/amdgpu: Limit BO list entry count to prevent resource exhaustion Jesse.Zhang
@ 2026-03-12 10:14 ` Christian König
2026-03-12 17:44 ` Alex Deucher
1 sibling, 0 replies; 6+ messages in thread
From: Christian König @ 2026-03-12 10:14 UTC (permalink / raw)
To: Jesse.Zhang, amd-gfx; +Cc: Alexander.Deucher
On 3/12/26 11:13, Jesse.Zhang 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 <christian.koenig@amd.com>
> Signed-off-by: Jesse Zhang <jesse.zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
> ---
> 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);
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] drm/amdgpu: Limit BO list entry count to prevent resource exhaustion
2026-03-12 10:13 [PATCH v2] drm/amdgpu: Limit BO list entry count to prevent resource exhaustion Jesse.Zhang
2026-03-12 10:14 ` Christian König
@ 2026-03-12 17:44 ` Alex Deucher
2026-03-12 17:48 ` Christian König
1 sibling, 1 reply; 6+ messages in thread
From: Alex Deucher @ 2026-03-12 17:44 UTC (permalink / raw)
To: Jesse.Zhang, Marek Olšák
Cc: amd-gfx, Alexander.Deucher, Christian Koenig
+ 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?
Alex
On Thu, Mar 12, 2026 at 6:13 AM Jesse.Zhang <Jesse.Zhang@amd.com> 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 <christian.koenig@amd.com>
> Signed-off-by: Jesse Zhang <jesse.zhang@amd.com>
> ---
> 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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] drm/amdgpu: Limit BO list entry count to prevent resource exhaustion
2026-03-12 17:44 ` Alex Deucher
@ 2026-03-12 17:48 ` Christian König
2026-03-12 20:43 ` Marek Olšák
0 siblings, 1 reply; 6+ messages in thread
From: Christian König @ 2026-03-12 17:48 UTC (permalink / raw)
To: Alex Deucher, Jesse.Zhang, Marek Olšák
Cc: amd-gfx, Alexander.Deucher
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 <Jesse.Zhang@amd.com> 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 <christian.koenig@amd.com>
>> Signed-off-by: Jesse Zhang <jesse.zhang@amd.com>
>> ---
>> 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
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] drm/amdgpu: Limit BO list entry count to prevent resource exhaustion
2026-03-12 17:48 ` Christian König
@ 2026-03-12 20:43 ` Marek Olšák
2026-03-13 11:54 ` Christian König
0 siblings, 1 reply; 6+ messages in thread
From: Marek Olšák @ 2026-03-12 20:43 UTC (permalink / raw)
To: Christian König
Cc: Alex Deucher, Jesse.Zhang, Marek Olšák, amd-gfx,
Alexander.Deucher
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
<christian.koenig@amd.com> 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 <Jesse.Zhang@amd.com> 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 <christian.koenig@amd.com>
> >> Signed-off-by: Jesse Zhang <jesse.zhang@amd.com>
> >> ---
> >> 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
> >>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] drm/amdgpu: Limit BO list entry count to prevent resource exhaustion
2026-03-12 20:43 ` Marek Olšák
@ 2026-03-13 11:54 ` Christian König
0 siblings, 0 replies; 6+ messages in thread
From: Christian König @ 2026-03-13 11:54 UTC (permalink / raw)
To: Marek Olšák
Cc: Alex Deucher, Jesse.Zhang, Marek Olšák, amd-gfx,
Alexander.Deucher
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
> <christian.koenig@amd.com> 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 <Jesse.Zhang@amd.com> 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 <christian.koenig@amd.com>
>>>> Signed-off-by: Jesse Zhang <jesse.zhang@amd.com>
>>>> ---
>>>> 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
>>>>
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-03-13 11:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-12 10:13 [PATCH v2] drm/amdgpu: Limit BO list entry count to prevent resource exhaustion Jesse.Zhang
2026-03-12 10:14 ` Christian König
2026-03-12 17:44 ` Alex Deucher
2026-03-12 17:48 ` Christian König
2026-03-12 20:43 ` Marek Olšák
2026-03-13 11:54 ` Christian König
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox