From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Retry gtt fault when out of fence register
Date: Mon, 16 Oct 2023 18:52:42 +0300 [thread overview]
Message-ID: <ZS1cSv7GZAf8SKfz@intel.com> (raw)
In-Reply-To: <2023101202-conjure-shortwave-6ebc@gregkh>
On Thu, Oct 12, 2023 at 06:12:26PM +0200, Greg KH wrote:
> On Thu, Oct 12, 2023 at 04:53:38PM +0300, Ville Syrjälä wrote:
> > On Thu, Oct 12, 2023 at 03:40:08PM +0200, Greg KH wrote:
> > > On Thu, Oct 12, 2023 at 04:28:01PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > >
> > > > If we can't find a free fence register to handle a fault in the GMADR
> > > > range just return VM_FAULT_NOPAGE without populating the PTE so that
> > > > userspace will retry the access and trigger another fault. Eventually
> > > > we should find a free fence and the fault will get properly handled.
> > > >
> > > > A further improvement idea might be to reserve a fence (or one per CPU?)
> > > > for the express purpose of handling faults without having to retry. But
> > > > that would require some additional work.
> > > >
> > > > Looks like this may have gotten broken originally by
> > > > commit 39965b376601 ("drm/i915: don't trash the gtt when running out of fences")
> > > > as that changed the errno to -EDEADLK which wasn't handle by the gtt
> > > > fault code either. But later in commit 2feeb52859fc ("drm/i915/gt: Fix
> > > > -EDEADLK handling regression") I changed it again to -ENOBUFS as -EDEADLK
> > > > was now getting used for the ww mutex dance. So this fix only makes
> > > > sense after that last commit.
> > > >
> > > > Cc: stable@vger.kernel.org
> > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9479
> > > > Fixes: 2feeb52859fc ("drm/i915/gt: Fix -EDEADLK handling regression")
> > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > >
> > > <formletter>
> > >
> > > This is not the correct way to submit patches for inclusion in the
> > > stable kernel tree. Please read:
> > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > > for how to do this properly.
> > >
> > > </formletter>
> >
> > Say what now?
>
> Sorry, my bot thought this was a patch sent only to stable, I've kicked
> it a bit and it shouldn't do that again...
Ah OK, thanks.
I was a bit worried that my reading comprehension had deterirated enough
that I couldn't figure iut what new requirement in the process I had
violated :)
--
Ville Syrjälä
Intel
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [PATCH] drm/i915: Retry gtt fault when out of fence register
Date: Mon, 16 Oct 2023 18:52:42 +0300 [thread overview]
Message-ID: <ZS1cSv7GZAf8SKfz@intel.com> (raw)
In-Reply-To: <2023101202-conjure-shortwave-6ebc@gregkh>
On Thu, Oct 12, 2023 at 06:12:26PM +0200, Greg KH wrote:
> On Thu, Oct 12, 2023 at 04:53:38PM +0300, Ville Syrjälä wrote:
> > On Thu, Oct 12, 2023 at 03:40:08PM +0200, Greg KH wrote:
> > > On Thu, Oct 12, 2023 at 04:28:01PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > >
> > > > If we can't find a free fence register to handle a fault in the GMADR
> > > > range just return VM_FAULT_NOPAGE without populating the PTE so that
> > > > userspace will retry the access and trigger another fault. Eventually
> > > > we should find a free fence and the fault will get properly handled.
> > > >
> > > > A further improvement idea might be to reserve a fence (or one per CPU?)
> > > > for the express purpose of handling faults without having to retry. But
> > > > that would require some additional work.
> > > >
> > > > Looks like this may have gotten broken originally by
> > > > commit 39965b376601 ("drm/i915: don't trash the gtt when running out of fences")
> > > > as that changed the errno to -EDEADLK which wasn't handle by the gtt
> > > > fault code either. But later in commit 2feeb52859fc ("drm/i915/gt: Fix
> > > > -EDEADLK handling regression") I changed it again to -ENOBUFS as -EDEADLK
> > > > was now getting used for the ww mutex dance. So this fix only makes
> > > > sense after that last commit.
> > > >
> > > > Cc: stable@vger.kernel.org
> > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9479
> > > > Fixes: 2feeb52859fc ("drm/i915/gt: Fix -EDEADLK handling regression")
> > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > >
> > > <formletter>
> > >
> > > This is not the correct way to submit patches for inclusion in the
> > > stable kernel tree. Please read:
> > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > > for how to do this properly.
> > >
> > > </formletter>
> >
> > Say what now?
>
> Sorry, my bot thought this was a patch sent only to stable, I've kicked
> it a bit and it shouldn't do that again...
Ah OK, thanks.
I was a bit worried that my reading comprehension had deterirated enough
that I couldn't figure iut what new requirement in the process I had
violated :)
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2023-10-16 15:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-12 13:28 [Intel-gfx] [PATCH] drm/i915: Retry gtt fault when out of fence register Ville Syrjala
2023-10-12 13:28 ` Ville Syrjala
2023-10-12 13:40 ` [Intel-gfx] " Greg KH
2023-10-12 13:40 ` Greg KH
2023-10-12 13:53 ` [Intel-gfx] " Ville Syrjälä
2023-10-12 13:53 ` Ville Syrjälä
2023-10-12 16:12 ` [Intel-gfx] " Greg KH
2023-10-12 16:12 ` Greg KH
2023-10-16 15:52 ` Ville Syrjälä [this message]
2023-10-16 15:52 ` Ville Syrjälä
2023-10-12 21:05 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2023-10-12 21:19 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-10-13 10:53 ` [Intel-gfx] [PATCH] " Andi Shyti
2023-10-16 15:49 ` Ville Syrjälä
2023-10-13 20:17 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for " 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=ZS1cSv7GZAf8SKfz@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stable@vger.kernel.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.