[PATCH v2] drm/panthor: Fix the "done_fence is initialized" detection logic

[PATCH v2] drm/panthor: Fix the "done_fence is initialized" detection logic

[Boris Brezillon]

After commit 541c8f2468b9 ("dma-buf: detach fence ops on signal v3"),
dma_fence::ops == NULL can't be used to check if the fence is initialized.
Use dma_fence_was_initialized() instead.

v2:
- Use dma_fence_was_initialized() instead of open-coding it

Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Philipp Stanner <phasta@kernel.org>
Cc: Christian König <christian.koenig@amd.com>
Reported-by: Steven Price <steven.price@arm.com>
Reported-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
---
 drivers/gpu/drm/panthor/panthor_sched.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
index bd703a2904a1..c15941ebe07a 100644
--- a/drivers/gpu/drm/panthor/panthor_sched.c
+++ b/drivers/gpu/drm/panthor/panthor_sched.c
@@ -3915,7 +3915,7 @@ static void job_release(struct kref *ref)
 	if (job->base.s_fence)
 		drm_sched_job_cleanup(&job->base);
 
-	if (job->done_fence && job->done_fence->ops)
+	if (dma_fence_was_initialized(job->done_fence))
 		dma_fence_put(job->done_fence);
 	else
 		dma_fence_free(job->done_fence);
-- 
2.53.0

Re: [PATCH v2] drm/panthor: Fix the "done_fence is initialized" detection logic

[Christian König]

On 3/9/26 13:43, Boris Brezillon wrote:
> After commit 541c8f2468b9 ("dma-buf: detach fence ops on signal v3"),
> dma_fence::ops == NULL can't be used to check if the fence is initialized.
> Use dma_fence_was_initialized() instead.
> 
> v2:
> - Use dma_fence_was_initialized() instead of open-coding it
> 
> Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> Cc: Philipp Stanner <phasta@kernel.org>
> Cc: Christian König <christian.koenig@amd.com>
> Reported-by: Steven Price <steven.price@arm.com>
> Reported-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3")
> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>

Reviewed-by: Christian König <christian.koenig@amd.com>

> ---
>  drivers/gpu/drm/panthor/panthor_sched.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
> index bd703a2904a1..c15941ebe07a 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -3915,7 +3915,7 @@ static void job_release(struct kref *ref)
>  	if (job->base.s_fence)
>  		drm_sched_job_cleanup(&job->base);
>  
> -	if (job->done_fence && job->done_fence->ops)
> +	if (dma_fence_was_initialized(job->done_fence))
>  		dma_fence_put(job->done_fence);
>  	else
>  		dma_fence_free(job->done_fence);

Re: [PATCH v2] drm/panthor: Fix the "done_fence is initialized" detection logic

[Nicolas Frattaroli]

On Monday, 9 March 2026 13:43:18 Central European Standard Time Boris Brezillon wrote:
> After commit 541c8f2468b9 ("dma-buf: detach fence ops on signal v3"),
> dma_fence::ops == NULL can't be used to check if the fence is initialized.
> Use dma_fence_was_initialized() instead.
> 
> v2:
> - Use dma_fence_was_initialized() instead of open-coding it
> 
> Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> Cc: Philipp Stanner <phasta@kernel.org>
> Cc: Christian König <christian.koenig@amd.com>
> Reported-by: Steven Price <steven.price@arm.com>
> Reported-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3")
> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
> ---
>  drivers/gpu/drm/panthor/panthor_sched.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
> index bd703a2904a1..c15941ebe07a 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -3915,7 +3915,7 @@ static void job_release(struct kref *ref)
>  	if (job->base.s_fence)
>  		drm_sched_job_cleanup(&job->base);
>  
> -	if (job->done_fence && job->done_fence->ops)
> +	if (dma_fence_was_initialized(job->done_fence))
>  		dma_fence_put(job->done_fence);
>  	else
>  		dma_fence_free(job->done_fence);
> 

Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

This also fixes the refcount underflow for me. Thanks!

Re: [PATCH v2] drm/panthor: Fix the "done_fence is initialized" detection logic

[Steven Price]

On 09/03/2026 12:43, Boris Brezillon wrote:
> After commit 541c8f2468b9 ("dma-buf: detach fence ops on signal v3"),
> dma_fence::ops == NULL can't be used to check if the fence is initialized.
> Use dma_fence_was_initialized() instead.
> 
> v2:
> - Use dma_fence_was_initialized() instead of open-coding it
> 
> Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> Cc: Philipp Stanner <phasta@kernel.org>
> Cc: Christian König <christian.koenig@amd.com>
> Reported-by: Steven Price <steven.price@arm.com>
> Reported-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3")
> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>

Reviewed-by: Steven Price <steven.price@arm.com>

> ---
>  drivers/gpu/drm/panthor/panthor_sched.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
> index bd703a2904a1..c15941ebe07a 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -3915,7 +3915,7 @@ static void job_release(struct kref *ref)
>  	if (job->base.s_fence)
>  		drm_sched_job_cleanup(&job->base);
>  
> -	if (job->done_fence && job->done_fence->ops)
> +	if (dma_fence_was_initialized(job->done_fence))
>  		dma_fence_put(job->done_fence);
>  	else
>  		dma_fence_free(job->done_fence);

Re: [PATCH v2] drm/panthor: Fix the "done_fence is initialized" detection logic

[Liviu Dudau]

On Mon, Mar 09, 2026 at 01:43:18PM +0100, Boris Brezillon wrote:
> After commit 541c8f2468b9 ("dma-buf: detach fence ops on signal v3"),
> dma_fence::ops == NULL can't be used to check if the fence is initialized.
> Use dma_fence_was_initialized() instead.
> 
> v2:
> - Use dma_fence_was_initialized() instead of open-coding it
> 
> Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> Cc: Philipp Stanner <phasta@kernel.org>
> Cc: Christian König <christian.koenig@amd.com>
> Reported-by: Steven Price <steven.price@arm.com>
> Reported-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3")
> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>

Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>

Best regards,
Liviu

> ---
>  drivers/gpu/drm/panthor/panthor_sched.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
> index bd703a2904a1..c15941ebe07a 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -3915,7 +3915,7 @@ static void job_release(struct kref *ref)
>  	if (job->base.s_fence)
>  		drm_sched_job_cleanup(&job->base);
>  
> -	if (job->done_fence && job->done_fence->ops)
> +	if (dma_fence_was_initialized(job->done_fence))
>  		dma_fence_put(job->done_fence);
>  	else
>  		dma_fence_free(job->done_fence);
> -- 
> 2.53.0
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Claude review: drm/panthor: Fix the "done_fence is initialized" detection logic

[Claude Code Review Bot]

Overall Series Review

Subject: drm/panthor: Fix the "done_fence is initialized" detection logic
Author: Boris Brezillon <boris.brezillon@collabora.com>
Patches: 5
Reviewed: 2026-03-10T12:23:45.443064

---

This is a single-patch fix for the panthor GPU scheduler, addressing a regression introduced by commit `541c8f2468b9 ("dma-buf: detach fence ops on signal v3")`. That commit made `dma_fence::ops` get set to `NULL` upon fence signaling, which broke panthor's use of `->ops` as a proxy for "was this fence initialized." The fix correctly switches to the dedicated `dma_fence_was_initialized()` helper.

The patch is clean, correct, and well-motivated. **Looks good.**

---
Generated by Claude Code Patch Reviewer

Claude review: drm/panthor: Fix the "done_fence is initialized" detection logic

[Claude Code Review Bot]

Patch Review

**Correctness**: The fix is correct. The old code:

```c
if (job->done_fence && job->done_fence->ops)
```

relied on `->ops` being non-NULL to distinguish an initialized (refcounted) fence from a merely allocated (kzalloc'd) one. After the upstream dma-buf change that clears `->ops` on signal, a signaled-but-initialized fence would incorrectly fall through to `dma_fence_free()` instead of `dma_fence_put()`, potentially causing a use-after-free or double-free.

The replacement:

```c
if (dma_fence_was_initialized(job->done_fence))
```

uses `dma_fence_was_initialized()` which checks `DMA_FENCE_FLAG_INITIALIZED_BIT` in `fence->flags` — a stable flag that survives signaling. It also handles the `fence == NULL` case internally (line 295 of `dma-fence.h`: `return fence && test_bit(...)`), so the NULL check that was previously part of the condition is preserved.

**Commit message**: Clear and well-structured. The `Fixes:` tag, `Reported-by:` tags, and v2 changelog are all present and correct.

**No issues found.** This is a straightforward, correct bug fix.

**Reviewed-by worthy**: Yes. The patch is minimal, well-targeted, and correctly uses the API designed for exactly this purpose.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/panthor: Fix the "done_fence is initialized" detection logic

[Claude Code Review Bot]

Overall Series Review

Subject: drm/panthor: Fix the "done_fence is initialized" detection logic
Author: Boris Brezillon <boris.brezillon@collabora.com>
Patches: 8
Reviewed: 2026-03-10T12:25:51.999443

---

This is a single-patch fix for the panthor GPU scheduler addressing a regression introduced by commit 541c8f2468b9 ("dma-buf: detach fence ops on signal v3"). That dma-buf change nullifies `dma_fence::ops` on signal, which broke panthor's `job_release()` logic that relied on `ops != NULL` to determine whether a fence was initialized (via `dma_fence_init()`) vs merely allocated (via `kzalloc`).

The approach — encoding an "initialized" flag in the low bit of the pointer — is a well-known kernel pattern and is sound given `dma_fence` alignment guarantees. The patch is generally well-structured, but I have concerns about correctness in certain paths.

**Verdict:** The fix addresses a real bug and the approach is reasonable, but there are issues that should be addressed before merging.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/panthor: Fix the "done_fence is initialized" detection logic

[Claude Code Review Bot]

Patch Review

**Positive aspects:**
- Clean encapsulation via `job_done_fence()` and `job_done_fence_initialized()` helpers
- Good use of `uintptr_t` to prevent accidental direct dereference
- The comment on the struct field explaining the encoding is helpful

**Issue 1 (potential bug): `job_release` calls `dma_fence_free()` on uninitialized NULL pointer**

In the patched `job_release()`:
```c
if (job_done_fence_initialized(job))
    dma_fence_put(job_done_fence(job));
else
    dma_fence_free(job_done_fence(job));
```

When `job->call_info.size == 0`, no `dma_fence` is allocated in `panthor_job_create()`, so `job->done_fence` is 0. If the job never reaches `queue_run_job()` (e.g., it's cleaned up early), then `job_done_fence_initialized()` is false, and `dma_fence_free(NULL)` is called. Looking at `dma_fence_free()`, it calls `kfree(rcu_to_ptr(fence))` — calling this with NULL should be safe since `kfree(NULL)` is a no-op, but only if `dma_fence_free` handles NULL gracefully. The original code had the same pattern (`dma_fence_free(NULL)`), so this isn't a regression, but it's worth noting.

**Issue 2 (correctness concern): Missing initialized bit in the `!job->call_info.size` early-return path**

In `queue_run_job()`, the `!job->call_info.size` path:
```c
if (!job->call_info.size) {
    done_fence = dma_fence_get(queue->fence_ctx.last_fence);

    job->done_fence = (uintptr_t)done_fence | DONE_FENCE_INITIALIZED;
    return dma_fence_get(done_fence);
}
```

This correctly sets `DONE_FENCE_INITIALIZED`. However, `queue->fence_ctx.last_fence` could theoretically be NULL on the very first submission to a queue. If `last_fence` is NULL, then `dma_fence_get(NULL)` returns NULL, and `job->done_fence` becomes `0 | 1 = 1`. Then `job_done_fence(job)` returns `(void *)(1 & ~1) = NULL`, but `job_done_fence_initialized()` returns true, so `job_release` would call `dma_fence_put(NULL)` which should crash. The original code had the same latent issue, so this is not a regression from this patch.

**Issue 3 (style): The `done_fence` variable initialization in `queue_run_job()`**

In the main path of `queue_run_job()`:
```c
done_fence = job_done_fence(job);
dma_fence_init(done_fence,
               &panthor_queue_fence_ops,
               &queue->fence_ctx.lock,
               queue->fence_ctx.id,
               atomic64_inc_return(&queue->fence_ctx.seqno));
job->done_fence |= DONE_FENCE_INITIALIZED;
```

The `done_fence` local variable was declared at the top of the function but the original code didn't assign it until later. In the patched version it's now assigned via `job_done_fence(job)` (extracting the raw pointer from `kzalloc` allocation in `panthor_job_create`). This is correct since the allocation path in `panthor_job_create` stores the pointer without the initialized bit:
```c
job->done_fence = (uintptr_t)done_fence;
```

Then after `dma_fence_init`, the bit is ORed in. The sequencing is correct.

**Issue 4 (minor): `dma_fence_free` in the else branch may be incorrect for the `!call_info.size` case**

After the patch, `job_release` does:
```c
if (job_done_fence_initialized(job))
    dma_fence_put(job_done_fence(job));
else
    dma_fence_free(job_done_fence(job));
```

The `else` branch covers the case where `done_fence` was `kzalloc`'d but never `dma_fence_init`'d (i.e., `queue_run_job` failed before calling `dma_fence_init`). In this case `dma_fence_free` is appropriate since it just does `kfree`. This is correct.

**Issue 5 (robustness): No compile-time assertion on dma_fence alignment**

The commit message states the lowest bit is "guaranteed to be unused because of the dma_fence alignment constraint," but there's no `static_assert` or `BUILD_BUG_ON` to verify this. Adding something like:

```c
BUILD_BUG_ON(__alignof__(struct dma_fence) < 2);
```

near the `DONE_FENCE_INITIALIZED` definition would make this assumption explicit and catch any future changes.

**Issue 6 (double dma_fence_get in out_unlock path):**

In `queue_run_job()`:
```c
queue->fence_ctx.last_fence = dma_fence_get(done_fence);

done_fence = dma_fence_get(done_fence);
```

This `done_fence = dma_fence_get(done_fence)` line is peculiar — it's getting a second reference on the already-local `done_fence` to return to the caller. This existed in the original code too (`done_fence = dma_fence_get(job->done_fence)`), so it's not a regression, but the rewrite makes the self-assignment more visually confusing. A comment would help clarify this is intentional (one ref for `last_fence`, one ref for the return value).

**Overall:** The fix is correct for the stated problem. I'd recommend adding a `BUILD_BUG_ON` for the alignment assumption. The patch is otherwise clean and well-contained.

---
Generated by Claude Code Patch Reviewer