public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	akash.goel@intel.com, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/7] drm/i915: Fix the offset issue for the stolen GEM objects
Date: Thu, 9 Jan 2014 10:58:35 +0100	[thread overview]
Message-ID: <20140109095835.GB4770@phenom.ffwll.local> (raw)
In-Reply-To: <20140109094520.GB3245@nuc-i3427.alporthouse.com>

On Thu, Jan 09, 2014 at 09:45:21AM +0000, Chris Wilson wrote:
> On Thu, Jan 09, 2014 at 11:00:17AM +0530, akash.goel@intel.com wrote:
> > From: Akash Goel <akash.goel@intel.com>
> > 
> > The 'offset' field of the 'scatterlist' structure was wrongly
> > programmed with the offset value from the base of stolen area,
> > whereas this field indicates the offset from where the interested
> > data starts within the PAGE pointed to by the 'page-link' field.
> > As a result when a new GEM object allocated from the stolen
> > area is mapped to GTT, it could lead to an overwrite of GTT entries
> > as the page count calculation will go wrong, refer the function
> > 'sg_page_count'.
> 
> This statement is incorrect since my use of sg here predates
> sg_page_iter.
> 
> The stolen sg has no page_link, the meaning of offset/length here are
> relative to the base of the stolen area.
> 
> However, if you wish to rephrase the above...

Actually we add offset both to sg->offset and adjust the dma_bus_addr
since this has been introduced in

commit 0104fdbb84d7adb0e377ed05bf75eba97b007544
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Nov 15 11:32:26 2012 +0000

    drm/i915: Introduce i915_gem_object_create_stolen()

But only Imre's conversion to the sg_page_iter started to pay any
attention to sg->offset in

commit 6e995e231a90ce7c5ce2a9eae23c8e22f4388db1
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon Feb 18 19:28:04 2013 +0200

    drm/i915: use for_each_sg_page for setting up the gtt ptes

So with a bit of commit message rewording and these references and cc:
stable this looks good.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2014-01-09  9:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09  5:30 [PATCH 1/7] drm/i915: Fix the offset issue for the stolen GEM objects akash.goel
2014-01-09  9:45 ` Chris Wilson
2014-01-09  9:58   ` Daniel Vetter [this message]
2014-01-09 11:08     ` Chris Wilson
  -- strict thread matches above, loose matches on Subject: below --
2014-01-13 10:54 akash.goel
2014-01-28  0:30 ` Jesse Barnes
2014-01-28  8:04   ` 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=20140109095835.GB4770@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=akash.goel@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