public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Philipp Stanner <phasta@mailbox.org>
To: "Christian König" <christian.koenig@amd.com>,
	"Danilo Krummrich" <dakr@kernel.org>,
	phasta@kernel.org
Cc: 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: Tue, 15 Apr 2025 14:54:36 +0200	[thread overview]
Message-ID: <573a616a5270d97f421a380e2e41c7e35d2f03e3.camel@mailbox.org> (raw)
In-Reply-To: <2dba3077-a770-4e00-9a7a-c744096ae876@amd.com>

On Tue, 2025-04-15 at 11:56 +0200, Christian König wrote:
> Am 14.04.25 um 16:27 schrieb Danilo Krummrich:
> > On Mon, Apr 14, 2025 at 10:54:25AM +0200, Philipp Stanner wrote:
> > > @Danilo:
> > > We have now 2 possible solutions for the firing WARN_ON floating.
> > > 
> > > Version A (Christian)
> > > Check in nouveau_fence_context_kill() whether a fence is already
> > > signaled before setting an error.
> > > 
> > > Version B (Me)
> > > This patch series here. Make sure that in Nouveau, only
> > > nouveau_fence_signal() signals fences.
> > > 
> > > 
> > > Both should do the trick. Please share a maintainer-preference so
> > > I can
> > > move on here.
> > Thanks for working on this Philipp.
> > 
> > If you don't want to rework things entirely, A seems to be
> > superior, since it
> > also catches the case when someone else would call
> > dma_fence_is_signaled() on a
> > nouveau fence (which could happen at any time). This doesn't seem
> > to be caught
> > by B, right?
> 
> Correct, yes. I would also keep it as simple as possible for
> backporting this bug fix.
> 
> On the other hand a rework is certainly appropriate including both
> nouveau as well as the DMA-fence calling rules. Especially that the
> DMA-fence framework calls the signaled callback with inconsistent
> locking is something we should fix.

Do you have a suggestion where to start?

I btw would still be interested in adding some sort of centralized
mechanism in dma_fence that the driver could use to do some cleanup
stuff once a fence gets signaled ^_^

P.

> 
> Regards,
> Christian.


  reply	other threads:[~2025-04-15 12:54 UTC|newest]

Thread overview: 23+ 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
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
     [not found]             ` <81a70ba6-94b1-4bb3-a0b2-9e8890f90b33@amd.com>
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 [this message]
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=573a616a5270d97f421a380e2e41c7e35d2f03e3.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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox