All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Matthew Brost" <matthew.brost@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 17/33] drm/xe: Add xe_migrate_copy_defrag() for on-GPU defrag copies
Date: Fri, 10 Jul 2026 22:17:31 +0000	[thread overview]
Message-ID: <20260710221731.B0E061F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260710215442.2444235-18-matthew.brost@intel.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Uninitialized variable `ccs_ofs` and kernel assertion failure in `xe_migrate_ccs_copy()` during `defrag_ccs` pass for TT memory on DGFX.
- [High] Defragmentation bypasses mandatory CCS metadata clearing for BOs without CCS, causing a security/information leak.
--

--- Patch [17]: [PATCH v2 17/33] drm/xe: Add xe_migrate_copy_defrag() for on-GPU defrag copies ---
commit b14779b7d60fb7520bb68944732a8ae6ceb089e7
Author: Matthew Brost <matthew.brost@intel.com>

drm/xe: Add xe_migrate_copy_defrag() for on-GPU defrag copies

Add xe_migrate_copy_defrag(), a copy helper for the upcoming page
defragmentation path where a single BO has its backing reallocated at a
more beneficial page order. The contents are relocated in up to two
passes (data and CCS) because they require opposite compression PAT
settings.

> diff --git a/drivers/gpu/drm/xe/xe_migrate.c b/drivers/gpu/drm/xe/xe_migrate.c
> index 9428dd5e7760c..956fd75454fa0 100644
> --- a/drivers/gpu/drm/xe/xe_migrate.c
> +++ b/drivers/gpu/drm/xe/xe_migrate.c
[ ... ]
> @@ -905,20 +931,29 @@ static struct dma_fence *__xe_migrate_copy(struct xe_migrate *m,
>  	bool src_is_vram = mem_type_is_vram(src->mem_type);
>  	bool dst_is_vram = mem_type_is_vram(dst->mem_type);
>  	bool type_device = src_bo->ttm.type == ttm_bo_type_device;
> -	bool needs_ccs_emit = type_device && xe_migrate_needs_ccs_emit(xe);
> +	bool needs_ccs_emit = type_device && xe_migrate_needs_ccs_emit(xe) &&
> +		!flags.defrag_copy;
> +	bool copy_ccs = xe_device_has_flat_ccs(xe) &&
> -		xe_bo_needs_ccs_pages(src_bo) && xe_bo_needs_ccs_pages(dst_bo);
> -	bool copy_system_ccs = copy_ccs && (!src_is_vram || !dst_is_vram);
> +		xe_bo_needs_ccs_pages(src_bo) && xe_bo_needs_ccs_pages(dst_bo) &&
> +		!flags.defrag_copy;
> +	bool copy_system_ccs = copy_ccs && (!src_is_vram || !dst_is_vram) &&
> +		!flags.defrag_ccs && !flags.defrag_copy;

[Severity: High]
If a BO does not use CCS, does forcing needs_ccs_emit to false during the
data pass bypass the mandatory security clearing of its CCS metadata?

In xe_migrate_copy_defrag(), if need_ccs is false, it performs the data pass
and returns early:

    struct dma_fence *fence =
        __xe_migrate_copy(..., (struct xe_migrate_copy_flags) {
            .defrag_copy = true,
        });

    if (IS_ERR(fence) || !need_ccs)
        return fence;

Since needs_ccs_emit is false when flags.defrag_copy is true,
xe_migrate_ccs_copy() is never called to clear the CCS metadata. Could this
leave stale cross-process data in the newly allocated destination pages?

[ ... ]
> @@ -1014,7 +1053,7 @@ static struct dma_fence *__xe_migrate_copy(struct xe_migrate *m,
>  		bb->cs[bb->len++] = MI_BATCH_BUFFER_END;
>  		update_idx = bb->len;
>  
> -		if (!copy_only_ccs)
> +		if (!flags.copy_only_ccs && !flags.defrag_ccs)
>  			emit_copy(gt, bb, src_L0_ofs, dst_L0_ofs, src_L0, XE_PAGE_SIZE);
>  
>  		if (needs_ccs_emit)

[Severity: Critical]
Can this pass an uninitialized ccs_ofs to xe_migrate_ccs_copy() and trigger
a kernel assertion failure on DGFX?

During a defrag_ccs pass for a TT memory BO, flags.defrag_ccs is true, which
forces copy_system_ccs to false:

    bool copy_system_ccs = copy_ccs && (!src_is_vram || !dst_is_vram) &&
        !flags.defrag_ccs && !flags.defrag_copy;

Because copy_system_ccs is false, the loop skips the initialization of ccs_ofs:

    if (copy_system_ccs) {
        ...
        batch_size += pte_update_size(..., &ccs_ofs, ...);
    }

However, needs_ccs_emit remains true (since flags.defrag_copy is false). This
causes xe_migrate_ccs_copy() to be called with the uninitialized ccs_ofs.

Furthermore, for TT memory on DGFX, both src_is_vram and dst_is_vram are false.
These are passed as the indirect flags to xe_migrate_ccs_copy():

    flush_flags = xe_migrate_ccs_copy(m, bb, src_L0_ofs,
                      IS_DGFX(xe) ? src_is_vram : src_is_pltt,
                      dst_L0_ofs,
                      IS_DGFX(xe) ? dst_is_vram : dst_is_pltt,
                      src_L0, ccs_ofs, copy_ccs);

Inside xe_migrate_ccs_copy(), this will trigger the assertion because both
indirect flags are false:

    xe_gt_assert(gt, src_is_indirect || dst_is_indirect);
    if (!src_is_indirect)
        src_ofs = ccs_ofs;

And then it programs the GPU copy engine with the uninitialized ccs_ofs,
which could lead to arbitrary GPU memory access or data corruption.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710215442.2444235-1-matthew.brost@intel.com?part=17

  reply	other threads:[~2026-07-10 22:17 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10 21:54 [PATCH v2 00/33] drm/ttm, drm/xe: Minimize dma-resv hold times and defragment sub-optimally backed BOs Matthew Brost
2026-07-10 21:54 ` [PATCH v2 01/33] drm/ttm/pool: Allow backing off reclaim at the beneficial order Matthew Brost
2026-07-10 22:08   ` sashiko-bot
2026-07-11 10:38   ` Christian König
2026-07-11 13:27     ` Matthew Brost
2026-07-10 21:54 ` [PATCH v2 02/33] drm/ttm/pool: Add ttm_pool_page_order_nodma() helper Matthew Brost
2026-07-11 10:39   ` Christian König
2026-07-11 12:40     ` Matthew Brost
2026-07-10 21:54 ` [PATCH v2 03/33] drm/ttm: Record sub-optimal page order allocations in ttm_tt Matthew Brost
2026-07-10 21:54 ` [PATCH v2 04/33] drm/ttm: Introduce ttm_pool_alloc_iter for __ttm_pool_alloc() Matthew Brost
2026-07-10 22:03   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 05/33] drm/ttm: Support defragmentation moves Matthew Brost
2026-07-10 22:09   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 06/33] drm/ttm: Add fault injection for beneficial-order allocation failures Matthew Brost
2026-07-10 21:54 ` [PATCH v2 07/33] drm/ttm: Harvest beneficial-order pages on defragmentation moves Matthew Brost
2026-07-10 22:19   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 08/33] drm/ttm: Bound page (re)allocation per defragmentation move Matthew Brost
2026-07-10 22:17   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 09/33] drm/ttm: Preallocate beneficial-order defrag pages outside the lock Matthew Brost
2026-07-10 22:09   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 10/33] drm/ttm: Add full out-of-lock preallocation for ttm_pool_alloc() Matthew Brost
2026-07-10 21:54 ` [PATCH v2 11/33] drm/gpusvm: Add a DMA-mapping accounting callback Matthew Brost
2026-07-10 22:10   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 12/33] drm/xe: Add debugfs stats for DMA-mapped pages per order Matthew Brost
2026-07-10 22:23   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 13/33] drm/xe: Flush L2 asynchronously in xe_bo_trigger_rebind() Matthew Brost
2026-07-10 22:18   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 14/33] drm/xe: Destroy page tables after unlinking all VMAs on VM close Matthew Brost
2026-07-10 21:54 ` [PATCH v2 15/33] drm/xe: Track BOs backed at a sub-optimal page order Matthew Brost
2026-07-10 22:18   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 16/33] drm/xe: Back off beneficial-order reclaim under defrag pressure Matthew Brost
2026-07-10 21:54 ` [PATCH v2 17/33] drm/xe: Add xe_migrate_copy_defrag() for on-GPU defrag copies Matthew Brost
2026-07-10 22:17   ` sashiko-bot [this message]
2026-07-10 21:54 ` [PATCH v2 18/33] drm/xe: Handle defrag moves in xe_bo_move() Matthew Brost
2026-07-10 22:25   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 19/33] drm/xe: Skip self-copies for borrowed pages on defrag moves Matthew Brost
2026-07-10 22:18   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 20/33] drm/xe: Add a page defragmentation worker Matthew Brost
2026-07-10 22:24   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 21/33] drm/xe: Add defrag GT stats Matthew Brost
2026-07-10 22:16   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 22/33] drm/xe: Add Kconfig.profile options for BO defrag configuration Matthew Brost
2026-07-10 21:54 ` [PATCH v2 23/33] drm/xe: Defrag using out-of-lock page preallocation Matthew Brost
2026-07-10 22:27   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 24/33] drm/xe: Add defrag profiling tracepoints Matthew Brost
2026-07-10 22:18   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 25/33] drm/xe: Preallocate system BO backing outside the dma-resv lock Matthew Brost
2026-07-10 22:21   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 26/33] drm/xe: Add tracepoint for xe_gem_create_ioctl Matthew Brost
2026-07-10 22:20   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 27/33] drm/xe: Add IOVA-based xe_res_cursor variant Matthew Brost
2026-07-10 22:24   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 28/33] drm/xe: Use IOVA-based DMA mapping for eligible tt BOs Matthew Brost
2026-07-10 21:54 ` [PATCH v2 29/33] drm/xe: Add per-device dependency scheduler for IOVA defrag finalize Matthew Brost
2026-07-10 22:27   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 30/33] drm/xe: Add packed copy-step IOVA mapping for defrag Matthew Brost
2026-07-10 21:54 ` [PATCH v2 31/33] drm/xe: Blit src-natural to dst-packed for defrag-IOVA copies Matthew Brost
2026-07-10 22:30   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 32/33] drm/xe: Finalize defrag-IOVA moves with post-copy job Matthew Brost
2026-07-10 22:36   ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 33/33] drm/amdgpu: Preallocate system BO pages outside the reservation lock Matthew Brost
2026-07-10 22:29   ` sashiko-bot
2026-07-10 22:03 ` ✗ CI.checkpatch: warning for drm/ttm, drm/xe: Minimize dma-resv hold times and defragment sub-optimally backed BOs Patchwork
2026-07-10 22:05 ` ✓ CI.KUnit: success " Patchwork
2026-07-10 22:20 ` ✗ CI.checksparse: warning " Patchwork
2026-07-10 22:40 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-07-11 10:33 ` [PATCH v2 00/33] " Christian König
2026-07-11 13:49   ` Matthew Brost

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=20260710221731.B0E061F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=matthew.brost@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.