From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Matthew Brost <matthew.brost@intel.com>,
intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: Christian Koenig <christian.koenig@amd.com>,
Huang Rui <ray.huang@amd.com>,
Matthew Auld <matthew.auld@intel.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v4 1/2] drm/ttm: Drop tt->restore after successful restore
Date: Tue, 05 May 2026 09:04:45 +0200 [thread overview]
Message-ID: <c2c5fe4cda479c02e18d658c91e55c9ab1cfc8bd.camel@linux.intel.com> (raw)
In-Reply-To: <20260505033013.3266938-2-matthew.brost@intel.com>
On Mon, 2026-05-04 at 20:30 -0700, Matthew Brost wrote:
> ttm_pool_restore_and_alloc() can successfully complete the restore
> process via ttm_pool_restore_commit(), but tt->restore is not dropped
> afterward. As a result, subsequent backup/restore flows observe what
> appears to be a completed restore, while in reality shmem handles are
> still installed in tt->pages, leading to the stack trace below.
>
> Fix this by freeing and dropping tt->restore in
> ttm_pool_restore_and_alloc() upon successful completion of the
> restore.
>
> 20545 [ 309.784531] RIP:
> 0010:sg_alloc_append_table_from_pages+0x38c/0x490
> 20547 [ 309.809570] RSP: 0018:ffffc9000623b838 EFLAGS: 00010206
> 20548 [ 309.814827] RAX: 0000000000001000 RBX: ffff88816e42a160 RCX:
> 0000000000000000
> 20549 [ 309.821986] RDX: 0000000000002000 RSI: 0000000000000003 RDI:
> 0000000000001000
> 20550 [ 309.829147] RBP: ffff88816e42a168 R08: 0000000000000002 R09:
> 000000007ffff000
> 20551 [ 309.836310] R10: ffffc9000623b928 R11: 0000000000000000 R12:
> 000000007ffff000
> 20552 [ 309.843471] R13: ffff88815ba5a100 R14: 0000000000000000 R15:
> 0000000000000001
> 20553 [ 309.850634] FS: 00007f9ff305e700(0000)
> GS:ffff888276c94000(0000) knlGS:0000000000000000
> 20554 [ 309.858749] CS: 0010 DS: 0000 ES: 0000 CR0:
> 0000000080050033
> 20555 [ 309.864519] CR2: 00007f9fca701000 CR3: 00000001565e2005 CR4:
> 0000000008f70ef0
> 20556 [ 309.871678] PKRU: 55555558
> 20557 [ 309.874403] Call Trace:
> 20558 [ 309.876866] <TASK>
> 20559 [ 309.878988] sg_alloc_table_from_pages_segment+0x60/0x100
> 20560 [ 309.884415] ? ttm_resource_manager_usage+0x36/0x60 [ttm]
> 20561 [ 309.889845] ? xe_tt_map_sg+0x7d/0xd0 [xe]
> 20562 [ 309.894045] xe_tt_map_sg+0x7d/0xd0 [xe]
> 20563 [ 309.898037] xe_bo_move+0x927/0xaa0 [xe]
> 20564 [ 309.902029] ttm_bo_handle_move_mem+0xba/0x170 [ttm]
> 20565 [ 309.907022] ttm_bo_validate+0xbe/0x190 [ttm]
> 20566 [ 309.911405] xe_bo_validate+0x9a/0x120 [xe]
> 20567 [ 309.915663] xe_gpuvm_validate+0xd9/0x140 [xe]
> 20568 [ 309.920206] drm_gpuvm_validate+0x2f0/0x5b0 [drm_gpuvm]
> 20569 [ 309.925459] ? drm_exec_lock_obj+0x63/0x210 [drm_exec]
> 20570 [ 309.930627] xe_vm_validate_rebind+0x46/0xb0 [xe]
> 20571 [ 309.935428] xe_exec_fn+0x20/0x40 [xe]
> 20572 [ 309.939249] drm_gpuvm_exec_lock+0x78/0xc0 [drm_gpuvm]
> 20573 [ 309.944410] xe_validation_exec_lock+0x5a/0xa0 [xe]
> 20574 [ 309.949385] xe_exec_ioctl+0x806/0xc30 [xe]
> 20575 [ 309.953639] ? ttwu_queue_wakelist+0xd9/0xf0
> 20576 [ 309.957935] ? __pfx_xe_exec_fn+0x10/0x10 [xe]
> 20577 [ 309.962449] ? __wake_up_common+0x73/0xa0
> 20578 [ 309.966482] ? __pfx_xe_exec_ioctl+0x10/0x10 [xe]
> 20579 [ 309.971263] drm_ioctl_kernel+0xa3/0x100
> 20580 [ 309.975209] drm_ioctl+0x213/0x440
> 20581 [ 309.978637] ? __pfx_xe_exec_ioctl+0x10/0x10 [xe]
> 20582 [ 309.983415] xe_drm_ioctl+0x67/0xd0 [xe]
> 20583 [ 309.987408] __x64_sys_ioctl+0x7f/0xd0
>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Christian Koenig <christian.koenig@amd.com>
> Cc: Huang Rui <ray.huang@amd.com>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> Cc: stable@vger.kernel.org
> Fixes: b63d715b8090 ("drm/ttm/pool, drm/ttm/tt: Provide a helper to
> shrink pages")
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>
> ---
>
> v3:
> - Call ttm_pool_apply_caching after freeing local restore (sashiko)
> - Save alloc in snapshot on restore failure (sashiko)
> v4:
> - Actual 'Save alloc in snapshot on restore failure (sashiko)'
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 19 +++++++++++++++----
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c
> b/drivers/gpu/drm/ttm/ttm_pool.c
> index 278bbe7a11ad..c7aab60b7f01 100644
> --- a/drivers/gpu/drm/ttm/ttm_pool.c
> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> @@ -902,6 +902,7 @@ int ttm_pool_restore_and_alloc(struct ttm_pool
> *pool, struct ttm_tt *tt,
> {
> struct ttm_pool_tt_restore *restore = tt->restore;
> struct ttm_pool_alloc_state alloc;
> + int ret;
>
> if (WARN_ON(!ttm_tt_is_backed_up(tt)))
> return -EINVAL;
> @@ -925,14 +926,24 @@ int ttm_pool_restore_and_alloc(struct ttm_pool
> *pool, struct ttm_tt *tt,
> } else {
> alloc = restore->snapshot_alloc;
> if (ttm_pool_restore_valid(restore)) {
> - int ret = ttm_pool_restore_commit(restore,
> tt->backup,
> - ctx,
> &alloc);
> + ret = ttm_pool_restore_commit(restore, tt-
> >backup,
> + ctx, &alloc);
>
> - if (ret)
> + if (ret) {
> + restore->snapshot_alloc = alloc;
> return ret;
> + }
> }
> - if (!alloc.remaining_pages)
> + if (!alloc.remaining_pages) {
> + kfree(tt->restore);
> + tt->restore = NULL;
> +
> + ret = ttm_pool_apply_caching(&alloc);
return ttm_pool_apply_caching(&alloc) ?
Otherwise LGTM.
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> + if (ret)
> + return ret;
> +
> return 0;
> + }
> }
>
> return __ttm_pool_alloc(pool, tt, ctx, &alloc, restore);
next prev parent reply other threads:[~2026-05-05 7:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260505033013.3266938-1-matthew.brost@intel.com>
2026-05-05 3:30 ` [PATCH v4 1/2] drm/ttm: Drop tt->restore after successful restore Matthew Brost
2026-05-05 7:04 ` Thomas Hellström [this message]
2026-05-05 17:35 ` Matthew Brost
2026-05-05 3:30 ` [PATCH v4 2/2] drm/ttm/pool: back up at native page order Matthew Brost
2026-05-05 9:02 ` Thomas Hellström
2026-05-05 17:36 ` 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=c2c5fe4cda479c02e18d658c91e55c9ab1cfc8bd.camel@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=airlied@gmail.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=ray.huang@amd.com \
--cc=simona@ffwll.ch \
--cc=stable@vger.kernel.org \
--cc=tzimmermann@suse.de \
/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