All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Steven Price <steven.price@arm.com>
Cc: Alyssa Rosenzweig <alyssa@collabora.com>,
	Rob Herring <robh+dt@kernel.org>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	Robin Murphy <robin.murphy@arm.com>,
	dri-devel@lists.freedesktop.org, Icecream95 <ixn@keemail.me>,
	stable@vger.kernel.org
Subject: Re: [PATCH v2 01/12] drm/panfrost: Make sure MMU context lifetime is not bound to panfrost_priv
Date: Mon, 21 Jun 2021 16:44:11 +0200	[thread overview]
Message-ID: <20210621164411.20eeacd4@collabora.com> (raw)
In-Reply-To: <828f1e50-323e-7f67-009f-e465720e303c@arm.com>

On Mon, 21 Jun 2021 15:29:55 +0100
Steven Price <steven.price@arm.com> wrote:

> On 21/06/2021 14:57, Alyssa Rosenzweig wrote:
> >> Jobs can be in-flight when the file descriptor is closed (either because
> >> the process did not terminate properly, or because it didn't wait for
> >> all GPU jobs to be finished), and apparently panfrost_job_close() does
> >> not cancel already running jobs. Let's refcount the MMU context object
> >> so it's lifetime is no longer bound to the FD lifetime and running jobs
> >> can finish properly without generating spurious page faults.  
> > 
> > Remind me - why can't we hard stop in-flight jobs when the fd is closed?
> > I've seen cases where kill -9'ing a badly behaved process doesn't end
> > the fault storm, or unfreeze the desktop.
> >   
> 
> Hard-stopping the in-flight jobs would also make sense. But unless we
> want to actually hang the close() then there will be a period between
> issuing the hard-stop and actually having completed all jobs in the context.

Patch 10 is doing that, I just didn't want to backport all the
dependencies, so I kept it split in 2 halves: one patch fixing the
use-after-free bug, and the other part killing in-flight jobs.

> 
> But equally to be fair I've been cherry-picking this patch myself for
> quite some time, so we should just merge it and improve from there. So
> you can have my:
> 
> Reviewed-by: Steven Price <steven.price@arm.com>


WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Steven Price <steven.price@arm.com>
Cc: Icecream95 <ixn@keemail.me>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	dri-devel@lists.freedesktop.org,
	Alyssa Rosenzweig <alyssa@collabora.com>,
	Rob Herring <robh+dt@kernel.org>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	stable@vger.kernel.org, Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v2 01/12] drm/panfrost: Make sure MMU context lifetime is not bound to panfrost_priv
Date: Mon, 21 Jun 2021 16:44:11 +0200	[thread overview]
Message-ID: <20210621164411.20eeacd4@collabora.com> (raw)
In-Reply-To: <828f1e50-323e-7f67-009f-e465720e303c@arm.com>

On Mon, 21 Jun 2021 15:29:55 +0100
Steven Price <steven.price@arm.com> wrote:

> On 21/06/2021 14:57, Alyssa Rosenzweig wrote:
> >> Jobs can be in-flight when the file descriptor is closed (either because
> >> the process did not terminate properly, or because it didn't wait for
> >> all GPU jobs to be finished), and apparently panfrost_job_close() does
> >> not cancel already running jobs. Let's refcount the MMU context object
> >> so it's lifetime is no longer bound to the FD lifetime and running jobs
> >> can finish properly without generating spurious page faults.  
> > 
> > Remind me - why can't we hard stop in-flight jobs when the fd is closed?
> > I've seen cases where kill -9'ing a badly behaved process doesn't end
> > the fault storm, or unfreeze the desktop.
> >   
> 
> Hard-stopping the in-flight jobs would also make sense. But unless we
> want to actually hang the close() then there will be a period between
> issuing the hard-stop and actually having completed all jobs in the context.

Patch 10 is doing that, I just didn't want to backport all the
dependencies, so I kept it split in 2 halves: one patch fixing the
use-after-free bug, and the other part killing in-flight jobs.

> 
> But equally to be fair I've been cherry-picking this patch myself for
> quite some time, so we should just merge it and improve from there. So
> you can have my:
> 
> Reviewed-by: Steven Price <steven.price@arm.com>


  reply	other threads:[~2021-06-21 14:44 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-21 13:38 [PATCH v2 00/12] drm/panfrost: Misc fixes/improvements Boris Brezillon
2021-06-21 13:38 ` [PATCH v2 01/12] drm/panfrost: Make sure MMU context lifetime is not bound to panfrost_priv Boris Brezillon
2021-06-21 13:38   ` Boris Brezillon
2021-06-21 13:57   ` Alyssa Rosenzweig
2021-06-21 13:57     ` Alyssa Rosenzweig
2021-06-21 14:29     ` Steven Price
2021-06-21 14:29       ` Steven Price
2021-06-21 14:44       ` Boris Brezillon [this message]
2021-06-21 14:44         ` Boris Brezillon
2021-06-24  8:03   ` Boris Brezillon
2021-06-24  8:03     ` Boris Brezillon
2021-06-21 13:38 ` [PATCH v2 02/12] drm/panfrost: Get rid of the unused JS_STATUS_EVENT_ACTIVE definition Boris Brezillon
2021-06-21 14:34   ` Steven Price
2021-06-21 14:49     ` Boris Brezillon
2021-06-21 14:54       ` Steven Price
2021-06-21 13:38 ` [PATCH v2 03/12] drm/panfrost: Drop the pfdev argument passed to panfrost_exception_name() Boris Brezillon
2021-06-21 14:36   ` Steven Price
2021-06-21 13:38 ` [PATCH v2 04/12] drm/panfrost: Expose exception types to userspace Boris Brezillon
2021-06-21 14:49   ` Steven Price
2021-06-21 14:55     ` Boris Brezillon
2021-06-21 13:39 ` [PATCH v2 05/12] drm/panfrost: Disable the AS on unhandled page faults Boris Brezillon
2021-06-21 15:08   ` Boris Brezillon
2021-06-21 15:09   ` Steven Price
2021-06-21 15:32     ` Boris Brezillon
2021-06-21 13:39 ` [PATCH v2 06/12] drm/panfrost: Expose a helper to trigger a GPU reset Boris Brezillon
2021-06-21 15:10   ` Steven Price
2021-06-21 13:39 ` [PATCH v2 07/12] drm/panfrost: Reset the GPU when the AS_ACTIVE bit is stuck Boris Brezillon
2021-06-21 15:11   ` Steven Price
2021-06-21 13:39 ` [PATCH v2 08/12] drm/panfrost: Do the exception -> string translation using a table Boris Brezillon
2021-06-21 15:19   ` Steven Price
2021-06-21 15:46     ` Boris Brezillon
2021-06-21 13:39 ` [PATCH v2 09/12] drm/panfrost: Don't reset the GPU on job faults unless we really have to Boris Brezillon
2021-06-21 15:26   ` Steven Price
2021-06-21 13:39 ` [PATCH v2 10/12] drm/panfrost: Kill in-flight jobs on FD close Boris Brezillon
2021-06-21 15:31   ` Steven Price
2021-06-21 13:39 ` [PATCH v2 11/12] drm/panfrost: Make ->run_job() return an ERR_PTR() when appropriate Boris Brezillon
2021-06-21 15:33   ` Steven Price
2021-06-21 13:39 ` [PATCH v2 12/12] drm/panfrost: Shorten the fence signalling section Boris Brezillon
2021-06-21 15:43   ` Steven Price

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=20210621164411.20eeacd4@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=alyssa.rosenzweig@collabora.com \
    --cc=alyssa@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ixn@keemail.me \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=stable@vger.kernel.org \
    --cc=steven.price@arm.com \
    --cc=tomeu.vizoso@collabora.com \
    /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.