All of lore.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@kernel.org>
To: "Christian König" <christian.koenig@amd.com>
Cc: Philipp Stanner <phasta@kernel.org>,
	Lyude Paul <lyude@redhat.com>, David Airlie <airlied@gmail.com>,
	Simona Vetter <simona@ffwll.ch>,
	Sabrina Dubroca <sd@queasysnail.net>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/3] drm/nouveau: Prevent signaled fences in pending list
Date: Thu, 10 Apr 2025 14:21:14 +0200	[thread overview]
Message-ID: <Z_e3uihgYFvwmQ7C@pollux> (raw)
In-Reply-To: <d03c618e-aa4b-423b-9c50-143b8a197cac@amd.com>

On Thu, Apr 10, 2025 at 02:13:34PM +0200, Christian König wrote:
> Am 10.04.25 um 11:24 schrieb Philipp Stanner:
> > Nouveau currently relies on the assumption that dma_fences will only
> > ever get signaled through nouveau_fence_signal(), which takes care of
> > removing a signaled fence from the list nouveau_fence_chan.pending.
> >
> > This self-imposed rule is violated in nouveau_fence_done(), where
> > dma_fence_is_signaled() (somewhat surprisingly, considering its name)
> > can signal the fence without removing it from the list. This enables
> > accesses to already signaled fences through the list, which is a bug.
> >
> > In particular, it can race with nouveau_fence_context_kill(), which
> > would then attempt to set an error code on an already signaled fence,
> > which is illegal.
> >
> > In nouveau_fence_done(), the call to nouveau_fence_update() already
> > ensures to signal all ready fences. Thus, the signaling potentially
> > performed by dma_fence_is_signaled() is actually not necessary.
> >
> > Replace the call to dma_fence_is_signaled() with
> > nouveau_fence_base_is_signaled().
> >
> > Cc: <stable@vger.kernel.org> # 4.10+, precise commit not to be determined
> > 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 7cc84472cece..33535987d8ed 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
> > @@ -274,7 +274,7 @@ nouveau_fence_done(struct nouveau_fence *fence)
> >  			nvif_event_block(&fctx->event);
> >  		spin_unlock_irqrestore(&fctx->lock, flags);
> >  	}
> > -	return dma_fence_is_signaled(&fence->base);
> > +	return test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->base.flags);
> 
> See the code above that:
> 
>         if (fence->base.ops == &nouveau_fence_ops_legacy ||
>             fence->base.ops == &nouveau_fence_ops_uevent) {

I think this check is a bit pointless given that fence is already a struct
nouveau_fence. :)

  reply	other threads:[~2025-04-10 12:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-10  9:24 [PATCH 0/3] drm/nouveau: Fix & improve nouveau_fence_done() Philipp Stanner
2025-04-10  9:24 ` [PATCH 1/3] drm/nouveau: Prevent signaled fences in pending list Philipp Stanner
2025-04-10 12:13   ` Christian König
2025-04-10 12:21     ` Danilo Krummrich [this message]
2025-04-10 12:42       ` Christian König
2025-04-10 12:58   ` Christian König
2025-04-10 13:09     ` Philipp Stanner
2025-04-10 13:16       ` Christian König
2025-04-10 15:36         ` Philipp Stanner
2025-04-11  9:29           ` Philipp Stanner
2025-04-11 11:05             ` Christian König
2025-04-11 12:44               ` Philipp Stanner
2025-04-11 13:06                 ` Christian König
2025-04-11 14:10                   ` Philipp Stanner
2025-04-14  8:54                     ` Philipp Stanner
2025-04-14 14:27                       ` Danilo Krummrich
2025-04-15  9:56                         ` Christian König
2025-04-15 12:54                           ` Philipp Stanner
2025-04-10  9:24 ` [PATCH 2/3] drm/nouveau: Remove surplus if-branch Philipp Stanner
2025-04-10 12:15   ` Christian König
2025-04-10  9:24 ` [PATCH 3/3] drm/nouveau: Add helper to check base fence Philipp Stanner
2025-04-10  9:51 ` [PATCH 0/3] drm/nouveau: Fix & improve nouveau_fence_done() Philipp Stanner
2025-04-10 12:18   ` Christian König
2025-04-10 13:18     ` Philipp Stanner

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=Z_e3uihgYFvwmQ7C@pollux \
    --to=dakr@kernel.org \
    --cc=airlied@gmail.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=lyude@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=phasta@kernel.org \
    --cc=sd@queasysnail.net \
    --cc=simona@ffwll.ch \
    --cc=stable@vger.kernel.org \
    --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 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.