Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Piórkowski, Piotr" <piotr.piorkowski@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v5 2/4] drm/xe/kunit: Extend GuC ID manager split-pool coverage
Date: Mon, 05 Oct 2026 09:04:35 +0000	[thread overview]
Message-ID: <20261005090435.E847A1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261005085132.3720685-3-piotr.piorkowski@intel.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] test: xe_guc_id_mgr: check_used triggers idm_assert on allocation failure
- [Medium] test: xe_guc_id_mgr: missing early returns on failed ID reservations
--

commit e5671ad31dee2fc19148c70082f71c4bcc2e8f21
Author: Piotr Piórkowski <piotr.piorkowski@intel.com>
Subject: drm/xe/kunit: Extend GuC ID manager split-pool coverage

This commit expands the GuC ID manager KUnit tests to cover the new
usable/shareable pool model. It introduces tests for boundary conditions,
overlap, and partial initialization.

>     v3: Guard failed ID reservations before releasing test allocations.
>     v4: Avoid releasing unreserved ID ranges after failed test reservations.

[ ... ]

> diff --git a/drivers/gpu/drm/xe/tests/xe_guc_id_mgr_test.c b/drivers/gpu/drm/xe/tests/xe_guc_id_mgr_test.c
> index 78d3de46b7572..5fe71eac2e380 100644
> --- a/drivers/gpu/drm/xe/tests/xe_guc_id_mgr_test.c
> +++ b/drivers/gpu/drm/xe/tests/xe_guc_id_mgr_test.c

[ ... ]

> @@ -62,13 +93,13 @@ static void check_used(struct kunit *test)
>  
>  	for (n = 0; n < idm_total(idm); n++) {
>  		kunit_info(test, "n=%u", n);
> -		KUNIT_EXPECT_EQ(test, bitmap_weight(idm->bitmap, idm_total(idm)), n);
> +		KUNIT_EXPECT_EQ(test, test_idm_used_total(idm), n);
>  		KUNIT_EXPECT_GE(test, xe_guc_id_mgr_reserve_usable_locked(idm, 1), 0);
> -		KUNIT_EXPECT_EQ(test, bitmap_weight(idm->bitmap, idm_total(idm)), n + 1);
> +		KUNIT_EXPECT_EQ(test, test_idm_used_total(idm), n + 1);
>  	}
> -	KUNIT_EXPECT_EQ(test, bitmap_weight(idm->bitmap, idm_total(idm)), idm_total(idm));
> -	idm_release_chunk_locked(idm, 0, idm_total(idm));
> -	KUNIT_EXPECT_EQ(test, bitmap_weight(idm->bitmap, idm_total(idm)), 0);
> +	KUNIT_EXPECT_EQ(test, test_idm_used_total(idm), idm_total(idm));
> +	idm_release_chunk_locked(idm, 0, test_idm_used_total(idm));

[Severity: Medium]
If xe_guc_id_mgr_reserve_usable_locked() fails inside the loop above, the
KUNIT_EXPECT_GE() will record a failure, but execution continues. When the
loop finishes, test_idm_used_total(idm) will evaluate to 0.

Does this cause idm_release_chunk_locked() to be called with a count of 0?

Looking at xe_guc_id_mgr.c, idm_release_chunk_locked() starts with:
    idm_assert(idm, count);

Would calling this cleanup path with a count of 0 trigger this internal
assertion and result in a drm_WARN during a failed test?

> +	KUNIT_EXPECT_EQ(test, test_idm_used_total(idm), 0);
>  
>  	mutex_unlock(idm_mutex(idm));
>  }

[ ... ]

> +static void check_overlap_alloc(struct kunit *test)
> +{
> +	struct xe_guc_id_mgr *idm = test->priv;
> +	unsigned int total;
> +	int usable_id, shareable_id;
> +
> +	if (!require_iov_config_or_skip(test))
> +		return;
> +
> +	KUNIT_ASSERT_EQ(test, 0, idm_init(idm, GUC_ID_MAX, GUC_ID_MAX));
> +
> +	mutex_lock(idm_mutex(idm));
> +	total = idm_total(idm);
> +
> +	usable_id = xe_guc_id_mgr_reserve_usable_locked(idm, 2);
> +	KUNIT_EXPECT_EQ(test, usable_id, 0);

[Severity: Medium]
The commit message notes "v3: Guard failed ID reservations before releasing
test allocations" and "v4: Avoid releasing unreserved ID ranges after failed
test reservations." 

However, tests like check_overlap_alloc() and 
check_overlap_partial_shared_range_blocking() appear to be missing the early
return guards that were added to check_quota().

If xe_guc_id_mgr_reserve_usable_locked() fails, could negative IDs cascade
into subsequent test logic and release functions? Should there be an early
return guard like "if (usable_id < 0)" added here as well?

> +
> +	shareable_id = xe_guc_id_mgr_reserve_shareable_locked(idm, 3, 0);
> +	KUNIT_EXPECT_EQ(test, shareable_id, total - 3);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005085132.3720685-1-piotr.piorkowski@intel.com?part=2

  reply	other threads:[~2026-10-05  9:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-05  8:51 [PATCH v5 0/4] Split GuC ID space into usable and shareable pools Piórkowski, Piotr
2026-10-05  8:51 ` [PATCH v5 1/4] drm/xe/guc: Split GuC ID manager " Piórkowski, Piotr
2026-10-06  8:35   ` K V P, Satyanarayana
2026-10-05  8:51 ` [PATCH v5 2/4] drm/xe/kunit: Extend GuC ID manager split-pool coverage Piórkowski, Piotr
2026-10-05  9:04   ` sashiko-bot [this message]
2026-10-05  8:51 ` [PATCH v5 3/4] drm/xe/guc: Start use explicitly usable GuC IDs for for submission Piórkowski, Piotr
2026-10-08  6:04   ` K V P, Satyanarayana
2026-10-05  8:51 ` [PATCH v5 4/4] drm/xe/pf: Explicitly use shareable GuC IDs for VFs provisioning Piórkowski, Piotr
2026-10-08  6:16   ` K V P, Satyanarayana
2026-10-05  9:23 ` ✓ CI.KUnit: success for Split GuC ID space into usable and shareable pools (rev5) Patchwork
2026-10-05 10:11 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-05 14:02 ` ✓ Xe.CI.FULL: " Patchwork

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=20261005090435.E847A1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=piotr.piorkowski@intel.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox