linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Philipp Stanner <phasta@mailbox.org>
To: "Christian König" <christian.koenig@amd.com>,
	phasta@kernel.org, "Lyude Paul" <lyude@redhat.com>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Sumit Semwal" <sumit.semwal@linaro.org>
Cc: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
	 linux-kernel@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [PATCH 2/2] drm/nouveau: Don't signal when killing the fence context
Date: Thu, 22 May 2025 14:42:33 +0200	[thread overview]
Message-ID: <e5d74c0be68d641171271cdff2e71ec5eb312377.camel@mailbox.org> (raw)
In-Reply-To: <eae0ff0f-31a6-433a-b255-9bdb4727a940@amd.com>

On Thu, 2025-05-22 at 14:34 +0200, Christian König wrote:
> On 5/22/25 14:20, Philipp Stanner wrote:
> > On Thu, 2025-05-22 at 14:06 +0200, Christian König wrote:
> > > On 5/22/25 13:25, Philipp Stanner wrote:
> > > > dma_fence_is_signaled_locked(), which is used in
> > > > nouveau_fence_context_kill(), can signal fences below the
> > > > surface
> > > > through a callback.
> > > > 
> > > > There is neither need for nor use in doing that when killing a
> > > > fence
> > > > context.
> > > > 
> > > > Replace dma_fence_is_signaled_locked() with
> > > > __dma_fence_is_signaled(), a
> > > > function which only checks, never signals.
> > > 
> > > That is not a good approach.
> > > 
> > > Having the __dma_fence_is_signaled() means that other would be
> > > allowed to call it as well.
> > > 
> > > But nouveau can do that here only because it knows that the fence
> > > was
> > > issued by nouveau.
> > > 
> > > What nouveau can to is to test the signaled flag directly, but
> > > that's
> > > what you try to avoid as well.
> > 
> > There's many parties who check the bit already.
> > 
> > And if Nouveau is allowed to do that, one can just as well provide
> > a
> > wrapper for it.
> 
> No, exactly that's what is usually avoided in cases like this here.
> 
> See all the functions inside include/linux/dma-fence.h can be used by
> everybody. It's basically the public interface of the dma_fence
> object.
> 
> So testing if a fence is signaled without calling the callback is
> only allowed by whoever implemented the fence.

Why?

See, who owns the callback? -> the driver which emitted the fence. If
the driver doesn't guarantee that all fences will be signaled, the
callback (always returning false) doesn't help you in any way.

I think the issue you're seeing is more that a party that only ever
checks a fence's state through callbacks (and doesn't signal them
through interrupts for example) would run danger of fences never
getting signaled.

But that's already the case if someone doesn't implement the callback.

The fundamental basis is always the same: The driver must guarantee
that all fences get signaled. Independently from other users checking
the fence this or that way, independently from the callback being
implemented.

> 
> In other words nouveau can test nouveau fences, i915 can test i915
> fences, amdgpu can test amdgpu fences etc... But if you have the
> wrapper that makes it officially allowed that nouveau starts testing
> i915 fences and that would be problematic.

I don't see the context here. That applies to the other functions as
well.


P.

> 
> Regards,
> Christian.
> 
> > 
> > That has the advantage of centralizing the responsibility and
> > documenting it.
> > 
> > P.
> > 
> > > 
> > > Regards,
> > > Christian.
> > > 
> > > > 
> > > > Signed-off-by: Philipp Stanner <phasta@kernel.org>
> > > > ---
> > > >  drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
> > > > b/drivers/gpu/drm/nouveau/nouveau_fence.c
> > > > index d5654e26d5bc..993b3dcb5db0 100644
> > > > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c
> > > > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
> > > > @@ -88,7 +88,7 @@ nouveau_fence_context_kill(struct
> > > > nouveau_fence_chan *fctx, int error)
> > > >  
> > > >  	spin_lock_irqsave(&fctx->lock, flags);
> > > >  	list_for_each_entry_safe(fence, tmp, &fctx->pending,
> > > > head)
> > > > {
> > > > -		if (error &&
> > > > !dma_fence_is_signaled_locked(&fence-
> > > > > base))
> > > > +		if (error && !__dma_fence_is_signaled(&fence-
> > > > > base))
> > > >  			dma_fence_set_error(&fence->base,
> > > > error);
> > > >  
> > > >  		if (nouveau_fence_signal(fence))
> > > 
> > 
> 


  reply	other threads:[~2025-05-22 12:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-22 11:25 [PATCH 1/2] dma-buf: Add __dma_fence_is_signaled() Philipp Stanner
2025-05-22 11:25 ` [PATCH 2/2] drm/nouveau: Don't signal when killing the fence context Philipp Stanner
2025-05-22 12:06   ` Christian König
2025-05-22 12:20     ` Philipp Stanner
2025-05-22 12:34       ` Christian König
2025-05-22 12:42         ` Philipp Stanner [this message]
2025-05-22 13:05           ` Christian König
2025-05-22 13:50             ` Danilo Krummrich
2025-05-22 15:01               ` Christian König
2025-05-22 12:57         ` Tvrtko Ursulin
2025-05-22 13:15           ` Christian König
2025-05-22 12:59         ` Danilo Krummrich
2025-05-22 13:09           ` Christian König
2025-05-22 13:16             ` Philipp Stanner
2025-05-22 13:24               ` Christian König
2025-05-22 13:43                 ` Philipp Stanner
2025-05-22 14:35                   ` Christian König
2025-05-22 13:41             ` Danilo Krummrich
2025-05-23 14:47 ` [PATCH 1/2] dma-buf: Add __dma_fence_is_signaled() Tvrtko Ursulin

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=e5d74c0be68d641171271cdff2e71ec5eb312377.camel@mailbox.org \
    --to=phasta@mailbox.org \
    --cc=airlied@gmail.com \
    --cc=christian.koenig@amd.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=lyude@redhat.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=phasta@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=sumit.semwal@linaro.org \
    /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).