From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] drm/i915: Don't drop pinned fences
Date: Mon, 27 Jan 2014 22:41:57 +0100 [thread overview]
Message-ID: <CAKMK7uEgiXGqsaXO88eZhQUjrcMr+AsMXUw+vcRLXJp-0Ci3nQ@mail.gmail.com> (raw)
In-Reply-To: <20140127212626.GE2508@nuc-i3427.alporthouse.com>
On Mon, Jan 27, 2014 at 10:26 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Mon, Jan 27, 2014 at 09:49:47PM +0100, Daniel Vetter wrote:
>> Userspace can currently provoke this when e.g. trying to use a pinned
>> scanout as a cursor or overlay target. Later on that might lead to
>> some fun fence pin count mayhem.
>>
>> Spurred by Ville's report that something goes wrong here and
>> originally I've thought that this might slip through the pwrite gtt
>> fastpath. But that one checks of obj tiling, so should be ok.
>>
>> But one thing that _does_ blow up is the vma unbinding with more than
>> one address space. The next patch will fix this.
>
> It's buggy behaviour, so if (WARN_ON(fence->pin_count) return -EBUSY;
>
> I did worry that we would then have some unexpected failure, a new EBUSY
> returning to userspace, but I think along the paths that can trigger it,
> we have already returned EBUSY in the (dim and distant) past.
Indeed we seem to have the required tiling checks everywhere. At first
I've had the WARN but then though userspace could sneak in through the
cursor/overlay code, but it can't. I'll update the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-01-27 21:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-27 20:49 [PATCH 1/2] drm/i915: Don't drop pinned fences Daniel Vetter
2014-01-27 20:49 ` [PATCH 2/2] drm/i915: Only do gtt cleanup in vma_unbind for the global vma Daniel Vetter
2014-01-27 21:26 ` [PATCH 1/2] drm/i915: Don't drop pinned fences Chris Wilson
2014-01-27 21:41 ` Daniel Vetter [this message]
2014-01-28 12:40 ` Ville Syrjälä
2014-02-14 13:06 ` [PATCH 1/3] " Daniel Vetter
2014-02-14 13:06 ` [PATCH 2/3] drm/i915: tune down user-triggerable dmesg noise in the cursor/overlay code Daniel Vetter
2014-02-14 17:29 ` Damien Lespiau
2014-02-14 18:02 ` Daniel Vetter
2014-02-14 13:06 ` [PATCH 3/3] drm/i915: Only do gtt cleanup in vma_unbind for the global vma Daniel Vetter
2014-02-14 13:23 ` Ville Syrjälä
2014-02-14 13:26 ` Chris Wilson
2014-05-12 17:46 ` [PATCH igt] tests/kms_fence_pin_leak: Exercise full ppgtt fence pin_count leak in the kernel ville.syrjala
2014-05-12 18:34 ` Daniel Vetter
2014-05-13 8:24 ` Ville Syrjälä
2014-05-13 8:42 ` Daniel Vetter
2014-05-13 8:56 ` [PATCH v2 " ville.syrjala
2014-05-14 16:14 ` [PATCH 3/3] drm/i915: Only do gtt cleanup in vma_unbind for the global vma Ville Syrjälä
2014-05-14 16:40 ` Daniel Vetter
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=CAKMK7uEgiXGqsaXO88eZhQUjrcMr+AsMXUw+vcRLXJp-0Ci3nQ@mail.gmail.com \
--to=daniel.vetter@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.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.