public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
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: Initialise userptr mmu_notifier serial to 1
Date: Fri, 11 Jul 2014 12:00:26 +0100	[thread overview]
Message-ID: <53BFC3CA.3010703@linux.intel.com> (raw)
In-Reply-To: <1405074481-4742-2-git-send-email-chris@chris-wilson.co.uk>


On 07/11/2014 11:28 AM, Chris Wilson wrote:
> During the range invalidate, we walk the list of buffers associated with
> the mmu_notifer and find the ones that overlap the range. An
> optimisation is made to speed up the iteration by assuming the previous
> iter is still valid whilst the tree is unmodified. This exposes a bug
> when a range invalidate is triggered after we have just created the
> mmu_notifier, but before attaching any buffers. In that case, we presume
> we have an unmodified list and start walking from the last iter which is
> NULL. Oops.
>
> The easiest fix is then to initialise the serial of the tree to 1.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> ---
>   drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index 7c38f50014db..8e9e91029aed 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -197,7 +197,7 @@ i915_mmu_notifier_get(struct drm_device *dev, struct mm_struct *mm)
>   	mmu->mm = mm;
>   	mmu->objects = RB_ROOT;
>   	mmu->count = 0;
> -	mmu->serial = 0;
> +	mmu->serial = 1;
>   	INIT_LIST_HEAD(&mmu->linear);
>   	mmu->is_linear = false;
>

Looks good to me and I think safe to merge in any case, so:

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

But it will be interesting to know what code managed to trigger this 
race, because as we discussed on IRC it would indicate some pretty wild 
userspace behaviour. Or lack of imagination on our part?

Tvrtko

  reply	other threads:[~2014-07-11 11:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-11 10:28 [PATCH 1/2] drm/i915: Abandon oom quickly if killed by a signal Chris Wilson
2014-07-11 10:28 ` [PATCH 2/2] drm/i915: Initialise userptr mmu_notifier serial to 1 Chris Wilson
2014-07-11 11:00   ` Tvrtko Ursulin [this message]
2014-07-11 11:06     ` Chris Wilson
2014-07-11 11:31       ` Tvrtko Ursulin
2014-07-11 11:35         ` Chris Wilson
2014-07-11 11:53           ` Tvrtko Ursulin
2014-07-11 14:02       ` Daniel Vetter
2014-07-11 14:06         ` Tvrtko Ursulin
2014-07-15  8:08           ` 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=53BFC3CA.3010703@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