All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Arunpravin Paneer Selvam" <arunpravin.paneerselvam@amd.com>
Cc: dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2] gpu/buddy: add range-restricted contiguous allocation fallback
Date: Wed, 30 Sep 2026 06:31:30 +0000	[thread overview]
Message-ID: <20260930063131.69E241F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260930062117.585089-1-arunpravin.paneerselvam@amd.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] gpu/buddy: range-restricted alloc fails when free space exceeds range_end
--

commit 2ed4c9d1a70c51390968b65e939095ce52c8ee07
Author: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>

gpu/buddy: add range-restricted contiguous allocation fallback

A range + contiguous allocation rounds its size up to a power of two
and requires a naturally aligned free block of that size. The
non-range contiguous path already recovers from fragmentation via
__alloc_contig_try_harder(), which is now given a range window to
support the range + contiguous case.

> diff --git a/drivers/gpu/buddy.c b/drivers/gpu/buddy.c
> index 2f2aaadafe351..5265e1f6a3183 100644
> --- a/drivers/gpu/buddy.c
> +++ b/drivers/gpu/buddy.c
[ ... ]
> @@ -1734,20 +1722,24 @@ static int __alloc_contig_try_harder(struct gpu_buddy *mm,
[ ... ]
>  		if (!err) {
>  			/* Allocate the unaligned RHS offset using round_down */
>  			gpu_buddy_free_list_internal(mm, blocks);
> -			err = __alloc_contig_aligned_retry(mm, rhs_offset,
> -							   size,
> -							   min_block_size,
> -							   flags, blocks);
> -			if (!err)
> -				return 0;
> -			if (err != -ENOSPC) {
> -				gpu_buddy_free_list_internal(mm, blocks);
> -				return err;
> +
> +			aligned = round_down(rhs_offset, min_block_size);
> +			if (aligned >= range_start &&
> +			    aligned + size <= range_end) {
> +				err = __gpu_buddy_alloc_range(mm, aligned, size,
> +							      flags, NULL, blocks);
> +				if (!err)
> +					return 0;
> +				if (err != -ENOSPC) {
> +					gpu_buddy_free_list_internal(mm, blocks);
> +					return err;
> +				}
>  			}
>  			goto next;
>  		}

[Severity: High]
Does this skip the left-hand side (LHS) fallback when contiguous free space
exceeds range_end?

If __gpu_buddy_alloc_range() succeeds at finding free space starting at
rhs_offset, err is 0. If the free space extends beyond range_end, the newly
added check (aligned >= range_start && aligned + size <= range_end) might
fail. But since err is still 0, it hits the unconditional goto next.

By skipping to next, doesn't this bypass the LHS window-sliding logic below?
If there was valid free space to the left of rhs_offset that perfectly fits
the window, it appears it would be ignored, causing the allocator to return
-ENOSPC despite sufficient space existing within the requested range.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260930062117.585089-1-arunpravin.paneerselvam@amd.com?part=1

  parent reply	other threads:[~2026-09-30  6:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-30  6:21 [PATCH v2] gpu/buddy: add range-restricted contiguous allocation fallback Arunpravin Paneer Selvam
2026-09-30  6:29 ` ✓ CI.KUnit: success for " Patchwork
2026-09-30  6:31 ` sashiko-bot [this message]
2026-09-30  7:32 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-30  8:00 ` ✓ i915.CI.BAT: " Patchwork
2026-09-30 11:53 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-09-30 18:34 ` ✗ i915.CI.Full: " Patchwork
2026-10-01  7:06 ` [PATCH v2] " Arunpravin Paneer Selvam
2026-10-01 18:28 ` Matthew Auld
2026-10-05 14:14   ` Arunpravin Paneer Selvam
2026-10-06  9:57     ` Matthew Auld
2026-10-09  9:14       ` Arunpravin Paneer Selvam
2026-10-09 10:17         ` Matthew Auld

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=20260930063131.69E241F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=arunpravin.paneerselvam@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.