From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/i915: Serialise userptr gup with mmu-notifier
Date: Thu, 10 Jul 2014 13:30:20 +0100 [thread overview]
Message-ID: <53BE875C.2070202@linux.intel.com> (raw)
In-Reply-To: <1404984104-27169-2-git-send-email-chris@chris-wilson.co.uk>
On 07/10/2014 10:21 AM, Chris Wilson wrote:
> Jerome Glisse pointed out that get_user_pages() does not synchronize
> with concurrent invalidations of the VMA. As such if the backing vma is
> changed whilst the pages for the object are being grabbed for use by the
> GPU, we may end up with a random mixture of page references being held.
> Worse still as the mmu-notifier will believe that the VMA invalidation
> was complete and the old page references dropped.
>
> In order to serialise gup with mmu-notifier, we use a seqlock to detect
> when an invalidation has occurred in parallel to our gup and if so cancel
> the gup. The detection is a little coarse, but hopefully we never see
> contention here!
Looks good to me, but as we discussed on IRC all get_user_pages users
have this "problem" and I don't understand why it matters to us? How
would someone hit/exploit the race? By one thread manically modifying
mappings while another is creating userptr objects? Is there some other
legitimate way of it happening?
Tvrtko
next prev parent reply other threads:[~2014-07-10 12:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-10 9:21 [PATCH 1/2] drm/i915: Allow overlapping userptr objects Chris Wilson
2014-07-10 9:21 ` [PATCH 2/2] drm/i915: Serialise userptr gup with mmu-notifier Chris Wilson
2014-07-10 9:32 ` Chris Wilson
2014-07-10 12:30 ` Tvrtko Ursulin [this message]
2014-07-10 12:26 ` [PATCH 1/2] drm/i915: Allow overlapping userptr objects Tvrtko Ursulin
2014-07-10 12:40 ` Chris Wilson
2014-07-10 20:20 ` 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=53BE875C.2070202@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox