intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Philipp Stanner <phasta@mailbox.org>
To: "Kuehling, Felix" <felix.kuehling@amd.com>,
	"Philipp Stanner" <phasta@kernel.org>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Gustavo Padovan" <gustavo@padovan.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Tvrtko Ursulin" <tursulin@ursulin.net>,
	"Huang Rui" <ray.huang@amd.com>,
	"Matthew Auld" <matthew.auld@intel.com>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Lucas De Marchi" <lucas.demarchi@intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	 linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org,
	 amd-gfx@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	 intel-xe@lists.freedesktop.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH 2/6] amd/amdkfd: Ignore return code of dma_fence_signal()
Date: Thu, 27 Nov 2025 10:48:00 +0100	[thread overview]
Message-ID: <d46f753e660694ab46c65409a5e43f050b7eb2d9.camel@mailbox.org> (raw)
In-Reply-To: <cef83fed-5994-4c77-962c-9c7aac9f7306@amd.com>

On Wed, 2025-11-26 at 16:24 -0500, Kuehling, Felix wrote:
> 
> On 2025-11-26 08:19, Philipp Stanner wrote:
> > The return code of dma_fence_signal() is not really useful as there is
> > nothing reasonable to do if a fence was already signaled. That return
> > code shall be removed from the kernel.
> > 
> > Ignore dma_fence_signal()'s return code.
> 
> I think this is not correct. Looking at the comment in 
> evict_process_worker, we use the return value to decide a race 
> conditions where multiple threads are trying to signal the eviction 
> fence. Only one of them should schedule the restore work. And the other 
> ones need to increment the reference count to keep evictions balanced.

Thank you for pointing that out. Seems then amdkfd is the only user who
actually relies on the feature. See below

> 
> Regards,
>    Felix
> 
> 
> > 
> > Suggested-by: Christian König <christian.koenig@amd.com>
> > Signed-off-by: Philipp Stanner <phasta@kernel.org>
> > ---
> >   drivers/gpu/drm/amd/amdkfd/kfd_process.c | 5 ++---
> >   1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> > index ddfe30c13e9d..950fafa4b3c3 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> > @@ -1986,7 +1986,6 @@ kfd_process_gpuid_from_node(struct kfd_process *p, struct kfd_node *node,
> >   static int signal_eviction_fence(struct kfd_process *p)
> >   {
> >   	struct dma_fence *ef;
> > -	int ret;
> >   
> >   	rcu_read_lock();
> >   	ef = dma_fence_get_rcu_safe(&p->ef);
> > @@ -1994,10 +1993,10 @@ static int signal_eviction_fence(struct kfd_process *p)
> >   	if (!ef)
> >   		return -EINVAL;
> >   
> > -	ret = dma_fence_signal(ef);
> > +	dma_fence_signal(ef);

The issue now is that dma_fence_signal()'s return code is actually non-
racy, because check + bit-set are protected by lock.

Christian's new spinlock series would add a lock function for fences:
https://lore.kernel.org/dri-devel/20251113145332.16805-5-christian.koenig@amd.com/


So I suppose this should work:

dma_fence_lock_irqsave(ef, flags);
if (dma_fence_test_signaled_flag(ef)) {
	dma_fence_unlock_irqrestore(ef, flags);
	return true;
}
dma_fence_signal_locked(ef);
dma_fence_unlock_irqrestore(ef, flags);

return false;


+ some cosmetic adjustments for the boolean of course.


Would that fly and be reasonable? @Felix, Christian.


P.

  reply	other threads:[~2025-12-01 13:39 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-26 13:19 [PATCH 0/6] dma-fence: Remove return code of dma_fence_signal() et al Philipp Stanner
2025-11-26 13:19 ` [PATCH 1/6] dma-buf/dma-fence: Add dma_fence_test_signaled_flag() Philipp Stanner
2025-11-26 16:41   ` Matthew Brost
2025-11-26 16:55     ` Matthew Brost
2025-11-27  8:11       ` Christian König
2025-11-27  9:16         ` Philipp Stanner
2025-11-27 10:01           ` Christian König
2025-11-27 10:16             ` Philipp Stanner
2025-11-28 20:01               ` Matthew Brost
2025-11-26 22:32   ` Andi Shyti
2025-11-26 13:19 ` [PATCH 2/6] amd/amdkfd: Ignore return code of dma_fence_signal() Philipp Stanner
2025-11-26 21:24   ` Kuehling, Felix
2025-11-27  9:48     ` Philipp Stanner [this message]
2025-11-27  9:55       ` Christian König
2025-11-27 15:08         ` Kuehling, Felix
2025-11-27 15:43           ` Philipp Stanner
2025-11-26 13:19 ` [PATCH 3/6] drm/gpu/xe: Ignore dma_fenc_signal() return code Philipp Stanner
2025-11-26 16:48   ` Matthew Brost
2025-11-26 22:56   ` Andi Shyti
2025-11-26 23:56     ` Matthew Brost
2025-11-27 13:37       ` Andi Shyti
2025-11-27 13:51         ` Philipp Stanner
2025-11-27 17:19           ` Andi Shyti
2025-11-26 13:19 ` [PATCH 4/6] dma-buf: Don't misuse dma_fence_signal() Philipp Stanner
2025-11-26 13:19 ` [PATCH 5/6] drm/ttm: Remove return check of dma_fence_signal() Philipp Stanner
2025-11-26 13:19 ` [PATCH 6/6] dma-buf/dma-fence: Remove return code of signaling-functions Philipp Stanner
2025-11-26 14:02 ` [PATCH 0/6] dma-fence: Remove return code of dma_fence_signal() et al Christian König
2025-11-26 14:09   ` Philipp Stanner
2025-11-26 17:26     ` Matthew Brost
2025-12-01 19:53 ` ✗ i915.CI.BAT: failure for dma-fence: Remove return code of dma_fence_signal() et al. (rev2) 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=d46f753e660694ab46c65409a5e43f050b7eb2d9.camel@mailbox.org \
    --to=phasta@mailbox.org \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=felix.kuehling@amd.com \
    --cc=gustavo@padovan.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthew.auld@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=mripard@kernel.org \
    --cc=phasta@kernel.org \
    --cc=ray.huang@amd.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=sumit.semwal@linaro.org \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tursulin@ursulin.net \
    --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;
as well as URLs for NNTP newsgroup(s).