On Fri, Mar 20, 2026 at 10:43 AM Louis Chauvet <[email protected]> wrote: > > On Fri, 13 Mar 2026 07:20:28 -0600, Jim Cromie <[email protected]> wrote: > > [...] > > drm_test_buddy_alloc_exceeds_max_order() uses the on a u64 value, > > where they silently truncate the 10GB allocation, giving unexpected > > success in DRM-CI. (see below the snip). > > > > Fix this by replacing the standard macros with safe 64-bit > > power-of-two calculations using ilog2(). > > This is a general DRM bug, if you send a new iteration, can you move it at > then start so it can be applied easly? >
Yes. I also sent it separately so it could be just picked up. > > > > > > diff --git a/drivers/gpu/buddy.c b/drivers/gpu/buddy.c > > index b27761246d4b..ff158cc1d27e 100644 > > --- a/drivers/gpu/buddy.c > > +++ b/drivers/gpu/buddy.c > > @@ -915,7 +915,7 @@ static int __alloc_contig_try_harder(struct gpu_buddy > > *mm, > > u64 modify_size; > > int err; > > > > - modify_size = rounddown_pow_of_two(size); > > + modify_size = 1ULL << ilog2(size); > > Thanks for catching this issue! > > To avoid this kind of issue later / in other parts of the kernel, maybe you > can change the macro itself to properly handle u64? I am thinking about > something similar to ilog2[1]: > > ( \ > (sizeof(n) <= 4) ? \ > __rounddown_pow_of_two_u32(n) : \ > __rounddown_pow_of_two_u64(n) \ > ) > > [1]:https://elixir.bootlin.com/linux/v6.19.8/source/include/linux/log2.h#L156-L164 > I will take a look, but if you have an itch, dont hesitate. > -- > Louis Chauvet <[email protected]>
