All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Natalie Vock" <natalie.vock@gmx.de>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 09/10] drm/ttm: support using drm_exec during eviction v4
Date: Fri, 03 Jul 2026 17:23:14 +0000	[thread overview]
Message-ID: <20260703172315.103391F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260703-ttm_2_drm_exec-v1-9-43685ac1286b@gmx.de>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] The drm_exec_lock_obj_report_dup helper fails to bypass the DRM_EXEC_IGNORE_DUPLICATES flag, causing premature unlocking and use-after-free of already-reserved buffers.
- [Medium] The trylock_only and no_wait_gpu flags are ignored when ctx->exec is set, forcing synchronous blocking locks during fast/non-blocking eviction passes.
--

commit 013bce350b89f0772194d9c2194cd802f5e36ff2
Author: Christian König <christian.koenig@amd.com>

drm/ttm: support using drm_exec during eviction v4

Allow specifying a drm_exec object in TTMs operation context which is
used to lock objects during eviction.

This allows to handle deadlocks much more gracefully and with that
avoid returning -ENOMEM on heavily contended domains.

> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index a53b25e8c2967..96699532817c2 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c

[ ... ]

> @@ -837,6 +838,8 @@ static bool ttm_lru_walk_trylock(struct ttm_bo_lru_cursor *curs,
>  	struct ttm_operation_ctx *ctx = curs->arg->ctx;
>  
>  	curs->needs_unlock = false;
> +	if (ctx->exec)
> +		return false;

[Severity: Medium]
Will this force a blocking lock during fast/non-blocking eviction passes?

By returning false unconditionally when ctx->exec is set, we bypass the
trylock here.

Later in __ttm_bo_lru_cursor_next(), the added !arg->ctx->exec check
prevents skipping the buffer, forcing a fall-through to
ttm_lru_walk_ticketlock() which performs a blocking lock. This seems to
ignore the trylock_only and no_wait_gpu flags.

>  	if (dma_resv_trylock(bo->base.resv)) {
>  		curs->needs_unlock = true;

[ ... ]

> @@ -857,7 +860,9 @@ static int ttm_lru_walk_ticketlock(struct ttm_bo_lru_cursor *curs,
>  	struct ttm_lru_walk_arg *arg = curs->arg;
>  	int ret;
>  
> -	if (arg->ctx->interruptible)
> +	if (arg->ctx->exec)
> +		ret = drm_exec_lock_obj_report_dup(arg->ctx->exec, &bo->base);
> +	else if (arg->ctx->interruptible)
>  		ret = dma_resv_lock_interruptible(bo->base.resv, arg->ticket);

[ ... ]

> @@ -937,12 +946,17 @@ static void ttm_bo_lru_cursor_cleanup_bo(struct ttm_bo_lru_cursor *curs)
>  {
>  	struct ttm_buffer_object *bo = curs->bo;
>  
> -	if (bo) {
> -		if (curs->needs_unlock)
> +	if (!bo)
> +		return;
> +
> +	if (curs->needs_unlock) {
> +		if (curs->arg->ctx->exec)
> +			drm_exec_unlock_obj(curs->arg->ctx->exec, &bo->base);

[Severity: Critical]
Can this cause a use-after-free for already-reserved buffers?

Looking at drm_exec_lock_obj_report_dup() used in ttm_lru_walk_ticketlock(),
it passes false for the always_report_duplicates parameter:

drivers/gpu/drm/drm_exec.c:drm_exec_lock_obj_report_dup() {
    return __drm_exec_lock_obj(exec, obj, false);
}

If DRM_EXEC_IGNORE_DUPLICATES is set, it returns 0 instead of -EALREADY for
duplicate locks. When this happens, ttm_lru_walk_ticketlock() will see
ret == 0 and set curs->needs_unlock = true.

Because of this, when ttm_bo_lru_cursor_cleanup_bo() runs, it sees
needs_unlock is true and calls drm_exec_unlock_obj() here, which unlocks
the object and drops its reference. This completely removes the buffer
from the caller's outer WW transaction.

> +		else
>  			dma_resv_unlock(bo->base.resv);
> -		ttm_bo_put(bo);
> -		curs->bo = NULL;
>  	}
> +	ttm_bo_put(bo);
> +	curs->bo = NULL;
>  }

[ ... ]

> @@ -1016,8 +1030,8 @@ __ttm_bo_lru_cursor_next(struct ttm_bo_lru_cursor *curs)
>  		if (ttm_lru_walk_trylock(curs, bo)) {
>  			bo_locked = true;
>  
> -		} else if (!arg->ticket || arg->ctx->no_wait_gpu ||
> -			   arg->trylock_only) {
> +		} else if ((!arg->ticket || arg->ctx->no_wait_gpu ||
> +			    arg->trylock_only) && !arg->ctx->exec) {
>  			spin_unlock(lru_lock);
>  			ttm_bo_put(bo);
>  			spin_lock(lru_lock);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-ttm_2_drm_exec-v1-0-43685ac1286b@gmx.de?part=9

  reply	other threads:[~2026-07-03 17:23 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-03 16:31 [PATCH 00/10] Use drm_exec to lock TTM buffers, respin Natalie Vock
2026-07-03 16:31 ` [PATCH 01/10] drm/exec: Add helper to bypass IGNORE_DUPLICATES flag Natalie Vock
2026-07-03 16:38   ` sashiko-bot
2026-07-06  8:43   ` Christian König
2026-07-07 12:09   ` Thomas Hellström
2026-07-07 12:28     ` Christian König
2026-07-07 12:41       ` Thomas Hellström
2026-07-07 12:54         ` Christian König
2026-07-07 13:12           ` Natalie Vock
2026-07-03 16:31 ` [PATCH 02/10] drm/ttm: replace TTMs refcount with the DRM refcount v4 Natalie Vock
2026-07-06 13:14   ` Thomas Hellström
2026-07-06 14:49     ` Christian König
2026-07-06 17:01       ` Thomas Hellström
2026-07-06 17:51         ` Matthew Brost
2026-07-06 17:53           ` Thomas Hellström
2026-07-06 18:03             ` Matthew Brost
2026-07-06 18:05               ` Matthew Brost
2026-07-07  6:30                 ` Thomas Hellström
2026-07-06 18:03           ` Thomas Hellström
2026-07-06 18:23         ` Christian König
2026-07-06 22:26           ` Dave Airlie
2026-07-07  6:56           ` Thomas Hellström
2026-07-07  7:35             ` Natalie Vock
2026-07-07  8:48             ` Christian König
2026-07-07  9:53               ` Thomas Hellström
2026-07-07 12:52                 ` Christian König
2026-07-07 14:07                   ` Thomas Hellström
2026-07-03 16:31 ` [PATCH 03/10] drm/ttm: remove ttm_lru_walk_ops Natalie Vock
2026-07-06 12:34   ` Thomas Hellström
2026-07-06 13:05     ` Christian König
2026-07-06 16:31       ` Matthew Brost
2026-07-06 13:08     ` Natalie Vock
2026-07-03 16:31 ` [PATCH 04/10] drm/ttm: grab BO reference before locking it Natalie Vock
2026-07-07 12:12   ` Thomas Hellström
2026-07-03 16:31 ` [PATCH 05/10] drm/ttm: switch to ttm_bo_lru_for_each_reserved_guarded for swapout Natalie Vock
2026-07-03 16:55   ` sashiko-bot
2026-07-07 12:17   ` Thomas Hellström
2026-07-03 16:31 ` [PATCH 06/10] drm/ttm: move zombie handling into ttm_bo_evict Natalie Vock
2026-07-07 12:24   ` Thomas Hellström
2026-07-03 16:31 ` [PATCH 07/10] drm/ttm: use ttm_bo_lru_for_each_reserved_guarded in evict_all Natalie Vock
2026-07-03 17:10   ` sashiko-bot
2026-07-07 12:35   ` Thomas Hellström
2026-07-03 16:31 ` [PATCH 08/10] drm/xe: remove workaround for TTM internals Natalie Vock
2026-07-03 17:10   ` sashiko-bot
2026-07-07 11:52   ` Thomas Hellström
2026-07-03 16:31 ` [PATCH 09/10] drm/ttm: support using drm_exec during eviction v4 Natalie Vock
2026-07-03 17:23   ` sashiko-bot [this message]
2026-07-07 12:48   ` Thomas Hellström
2026-07-03 16:31 ` [PATCH 10/10] drm/amdgpu: use drm_exec during BO validation Natalie Vock
2026-07-03 17:24   ` sashiko-bot
2026-07-03 17:26 ` ✗ LGCI.VerificationFailed: failure for Use drm_exec to lock TTM buffers, respin Patchwork
2026-07-03 17:47 ` 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=20260703172315.103391F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=natalie.vock@gmx.de \
    --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.