All of 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 v2 4/4] drm/xe/kunit: Add tests for PF-mem regions
Date: Fri, 21 Aug 2026 09:54:32 +0000	[thread overview]
Message-ID: <20260821095432.780921F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260821094601.607060-5-piotr.piorkowski@intel.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The hardcoded mock pointer `SZ_4G` truncates to `NULL` on 32-bit architectures, breaking KUnit tests.
- [Low] The out-of-bounds offset test case is shadowed by a page alignment check.
--

--- Patch [4]: [PATCH v2 4/4] drm/xe/kunit: Add tests for PF-mem regions ---
commit def1e04af372e808abcf812a9ee0ac48e736b86c
Author: Piotr Piórkowski <piotr.piorkowski@intel.com>

drm/xe/kunit: Add tests for PF-mem regions

Add KUnit tests for PF-mem VRAM regions to provide coverage for region
metadata, bounds checking, and CPU visibility constraints.

> diff --git a/drivers/gpu/drm/xe/tests/xe_vram.c b/drivers/gpu/drm/xe/tests/xe_vram.c
> new file mode 100644
> index 0000000000000..36a49fbef2206
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/tests/xe_vram.c
> @@ -0,0 +1,115 @@

[ ... ]

> +static struct xe_vram_region pfmem_parent(struct xe_device *xe, u64 io_size)
> +{
> +	struct xe_vram_region parent = {
> +		.xe = xe,
> +		.id = 0,
> +		.io_start = SZ_1G,
> +		.io_size = io_size,
> +		.dpa_base = SZ_2G,
> +		.mapping = (__force void __iomem *)SZ_4G,

[Severity: Medium]
Will this cast truncate to NULL on 32-bit architectures?

If this code is built on 32-bit architectures (for example, via COMPILE_TEST),
SZ_4G (0x100000000ULL) won't fit in a 32-bit pointer and truncates to NULL.

When xe_vram_region_init_pfmem() later delegates to vram_region_init(), it
checks if the mapping is NULL and fails with -ENOMEM instead of 0.

Could this cause the KUnit tests to unexpectedly fail on 32-bit builds?

> +		.usable_size = SZ_64M,
> +	};
> +
> +	return parent;
> +}

[ ... ]

> +static void pfmem_invalid_range(struct kunit *test)
> +{
> +	struct xe_device *xe = test->priv;
> +	struct xe_vram_region parent = pfmem_parent(xe, SZ_64M);
> +	struct xe_vram_region *vram;
> +
> +	vram = xe_vram_region_alloc_pfmem(xe, 0);
> +	KUNIT_ASSERT_NOT_NULL(test, vram);
> +	KUNIT_EXPECT_EQ(test, xe_vram_region_init_pfmem(vram, &parent, 0, 0), -EINVAL);
> +	KUNIT_EXPECT_EQ(test, xe_vram_region_init_pfmem(vram, &parent, SZ_64M + 1, SZ_4M), -EINVAL);

[Severity: Low]
Does this actually test the bounds check?

Since SZ_64M + 1 is not page-aligned, xe_vram_region_init_pfmem() will
evaluate the alignment check first and short-circuit to return -EINVAL.

It seems the offset > parent->usable_size bounds check would remain
completely untested here.

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

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

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21  9:45 [PATCH v2 0/4] Introduce PF-mem VRAM regions Piórkowski, Piotr
2026-08-21  9:45 ` [PATCH v2 1/4] drm/xe/vram: Add binding information to " Piórkowski, Piotr
2026-08-21  9:54   ` sashiko-bot
2026-08-21  9:45 ` [PATCH v2 2/4] drm/xe/ttm: Add PF-mem VRAM placement types for TTM Piórkowski, Piotr
2026-08-21  9:46 ` [PATCH v2 3/4] drm/xe/vram: Add initial support for PF-mem regions Piórkowski, Piotr
2026-08-21  9:46 ` [PATCH v2 4/4] drm/xe/kunit: Add tests " Piórkowski, Piotr
2026-08-21  9:54   ` sashiko-bot [this message]
2026-08-21  9:52 ` ✗ CI.checkpatch: warning for Introduce PF-mem VRAM regions (rev2) Patchwork
2026-08-21  9:53 ` ✓ CI.KUnit: success " Patchwork
2026-08-21 10:16 ` [PATCH v2 0/4] Introduce PF-mem VRAM regions Matthew Auld
2026-08-21 10:33 ` ✓ Xe.CI.BAT: success for Introduce PF-mem VRAM regions (rev2) Patchwork
2026-08-21 11:43 ` ✓ 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=20260821095432.780921F000E9@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 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.