All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Auld <matthew.auld@intel.com>
To: David Gow <david@ingeniumdigital.com>,
	Jim Cromie <jim.cromie@gmail.com>,
	"Maciej W . Rozycki" <macro@orcam.me.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arun Pravin <arunpravin.paneerselvam@amd.com>,
	Joel Fernandes <joelagnelf@nvidia.com>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	David Gow <david@davidgow.net>
Subject: Re: [PATCH 2/2] drm_buddy: fix power-of-2 rounding errs
Date: Fri, 21 Aug 2026 10:47:17 +0100	[thread overview]
Message-ID: <87ec838b-c73f-45d2-b90b-c696aa6017cc@intel.com> (raw)
In-Reply-To: <20260821091918.1902032-2-david@ingeniumdigital.com>

On 21/08/2026 10:19, David Gow wrote:
> From: Jim Cromie <jim.cromie@gmail.com>
> 
> The standard roundup_pow_of_two() and rounddown_pow_of_two() macros use
> unsigned long internally, which on 32-bit architectures (like arm32) is
> a 32-bit type.
> 
> drm_test_buddy_alloc_exceeds_max_order() uses these 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 those macros with the safe 64-bit power-of-two
> equivalents added in the previous patch.

Do we also need something like is_power_of_2_u64() ? I think we could 
then remove that from i915_utils.h

> 
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> Signed-off-by: David Gow <david@davidgow.net>
> ---
> 
> This should actually be version 13, I think, as it's just a rebase of v12
> here, where it was part of a large series of fixups:
> https://lore.kernel.org/all/20260326185413.1205870-40-jim.cromie@gmail.com/
> 
> The major changes since that version are:
> - Add the helper functions rounddown_pow_of_two64() and
>    roundup_pow_of_two64() (see patch 1) instead of open-coding them
> - Rebase now that the buddy allocator lives in drivers/gpu/buddy.c
>    instead of drivers/gpu/drm/drm_buddy.c
> 
> This is still breaking the gpu_test_buddy_alloc_exceeds_max_order
> KUnit test on 32-bit systems:
> [09:01:26]     # gpu_test_buddy_alloc_exceeds_max_order: EXPECTATION FAILED at drivers/gpu/tests/gpu_buddy_test.c:1429
> [09:01:26]     Expected err == -22, but
> [09:01:26]         err == 0 (0x0)
> [09:01:26] WARNING: drivers/gpu/buddy.c:508 at gpu_buddy_fini+0x244/0x2e0, CPU#0: kunit_try_catch/1595
> [09:01:26]     # gpu_test_buddy_alloc_exceeds_max_order: drivers/gpu/buddy.c:508: gpu_buddy_assert(gpu_buddy_block_is_free(mm->roots[i]))
> [09:01:26] WARNING: drivers/gpu/buddy.c:516 at gpu_buddy_fini+0x284/0x2e0, CPU#0: kunit_try_catch/1595
> [09:01:26]     # gpu_test_buddy_alloc_exceeds_max_order: drivers/gpu/buddy.c:508: gpu_buddy_assert(gpu_buddy_block_is_free(mm->roots[i]))
> [09:01:26] WARNING: drivers/gpu/buddy.c:516 at gpu_buddy_fini+0x284/0x2e0, CPU#0: kunit_try_catch/1595
> [09:01:26]     # gpu_test_buddy_alloc_exceeds_max_order: drivers/gpu/buddy.c:519: gpu_buddy_assert(!mm->used_scoreboard[i])
> [09:01:26] [FAILED] gpu_test_buddy_alloc_exceeds_max_order
> 
> Cheers,
> -- David
> 
> ---
>   drivers/gpu/buddy.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/buddy.c b/drivers/gpu/buddy.c
> index a5553fcec28c..64f41f1fe908 100644
> --- a/drivers/gpu/buddy.c
> +++ b/drivers/gpu/buddy.c
> @@ -1193,7 +1193,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 = rounddown_pow_of_two64(size);
>   	order = ilog2(modify_size) - ilog2(mm->chunk_size);
>   	if (order == 0)
>   		return -ENOSPC;
> @@ -1440,7 +1440,7 @@ int gpu_buddy_alloc_blocks(struct gpu_buddy *mm,
>   
>   	/* Roundup the size to power of 2 */
>   	if (flags & GPU_BUDDY_CONTIGUOUS_ALLOCATION) {
> -		size = roundup_pow_of_two(size);
> +		size = roundup_pow_of_two64(size);
>   		min_block_size = size;
>   		/*
>   		 * Normalize the requested size to min_block_size for regular allocations.


  parent reply	other threads:[~2026-08-21  9:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21  9:19 [PATCH 1/2] linux/log2.h: Add round{up,down}_pow_of_two64() David Gow
2026-08-21  9:19 ` [PATCH 2/2] drm_buddy: fix power-of-2 rounding errs David Gow
2026-08-21  9:43   ` sashiko-bot
2026-08-21  9:47   ` Matthew Auld [this message]
2026-08-21  9:30 ` [PATCH 1/2] linux/log2.h: Add round{up,down}_pow_of_two64() sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ec838b-c73f-45d2-b90b-c696aa6017cc@intel.com \
    --to=matthew.auld@intel.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arunpravin.paneerselvam@amd.com \
    --cc=david@davidgow.net \
    --cc=david@ingeniumdigital.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jim.cromie@gmail.com \
    --cc=joelagnelf@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@orcam.me.uk \
    --cc=simona@ffwll.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.