From: Thomas Hellstrom <thomas@shipmail.org>
To: Ben Skeggs <skeggsb@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: fix two regressions since move_notify changes
Date: Wed, 25 Jan 2012 18:32:55 +0100 [thread overview]
Message-ID: <4F203CC7.4010108@shipmail.org> (raw)
In-Reply-To: <1327469662-6248-1-git-send-email-skeggsb@gmail.com>
On 01/25/2012 06:34 AM, Ben Skeggs wrote:
> From: Ben Skeggs<bskeggs@redhat.com>
>
> Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
> regressions in the nouveau driver.
>
> move_notify() was originally able to presume that bo->mem is the old node,
> and new_mem is the new node. The above commit moves the call to
> move_notify() to after move() has been done, which means that now, sometimes,
> new_mem isn't the new node at all, bo->mem is, and new_mem points at a
> stale, possibly-just-been-killed-by-move node.
>
> This is clearly not a good situation. This patch reverts this change, and
> replaces it with a cleanup in the move() failure path instead.
>
> The second issue is that the call to move_notify() from cleanup_memtype_use()
> causes the TTM ghost objects to get passed into the driver. This is clearly
> bad as the driver knows nothing about these "fake" TTM BOs, and ends up
> accessing uninitialised memory.
>
> I worked around this in nouveau's move_notify() hook by ensuring the BO
> destructor was nouveau's. I don't particularly like this solution, and
> would rather TTM never pass the driver these objects. However, I don't
> clearly understand the reason why we're calling move_notify() here anyway
> and am happy to work around the problem in nouveau instead of breaking the
> behaviour expected by other drivers.
>
> Signed-off-by: Ben Skeggs<bskeggs@redhat.com>
> Cc: Jerome Glisse<j.glisse@gmail.com>
As mentioned in the lengthy email discussion, I don't like the ttm change,
but since we don't have time for anything better,
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++++
> drivers/gpu/drm/ttm/ttm_bo.c | 17 +++++++++++++----
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 724b41a..ec54364 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -812,6 +812,10 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct ttm_mem_reg *new_mem)
> struct nouveau_bo *nvbo = nouveau_bo(bo);
> struct nouveau_vma *vma;
>
> + /* ttm can now (stupidly) pass the driver bos it didn't create... */
> + if (bo->destroy != nouveau_bo_del_ttm)
> + return;
> +
> list_for_each_entry(vma,&nvbo->vma_list, head) {
> if (new_mem&& new_mem->mem_type == TTM_PL_VRAM) {
> nouveau_vm_map(vma, new_mem->mm_node);
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 2f0eab6..7c3a57d 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -404,6 +404,9 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object *bo,
> }
> }
>
> + if (bdev->driver->move_notify)
> + bdev->driver->move_notify(bo, mem);
> +
> if (!(old_man->flags& TTM_MEMTYPE_FLAG_FIXED)&&
> !(new_man->flags& TTM_MEMTYPE_FLAG_FIXED))
> ret = ttm_bo_move_ttm(bo, evict, no_wait_reserve, no_wait_gpu, mem);
> @@ -413,11 +416,17 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object *bo,
> else
> ret = ttm_bo_move_memcpy(bo, evict, no_wait_reserve, no_wait_gpu, mem);
>
> - if (ret)
> - goto out_err;
> + if (ret) {
> + if (bdev->driver->move_notify) {
> + struct ttm_mem_reg tmp_mem = *mem;
> + *mem = bo->mem;
> + bo->mem = tmp_mem;
> + bdev->driver->move_notify(bo, mem);
> + bo->mem = *mem;
> + }
>
> - if (bdev->driver->move_notify)
> - bdev->driver->move_notify(bo, mem);
> + goto out_err;
> + }
>
> moved:
> if (bo->evicted) {
prev parent reply other threads:[~2012-01-25 17:32 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-15 21:31 [next] Null pointer dereference in nouveau_vm_map_sg Martin Nyhus
2012-01-16 20:30 ` Jerome Glisse
2012-01-16 23:57 ` Martin Nyhus
2012-01-22 18:33 ` Konrad Rzeszutek Wilk
2012-01-24 22:33 ` Jerome Glisse
2012-01-25 0:12 ` Martin Nyhus
2012-01-25 16:54 ` Jerome Glisse
2012-01-25 5:34 ` [PATCH] drm/ttm: fix two regressions since move_notify changes Ben Skeggs
2012-01-25 7:43 ` Thomas Hellstrom
2012-01-25 8:05 ` Ben Skeggs
2012-01-25 8:39 ` Thomas Hellstrom
2012-01-25 9:41 ` Ben Skeggs
2012-01-25 14:33 ` Thomas Hellstrom
2012-01-25 15:21 ` Ben Skeggs
2012-01-25 15:37 ` Jerome Glisse
2012-01-25 17:15 ` Thomas Hellstrom
2012-01-25 17:19 ` Thomas Hellstrom
2012-01-25 18:12 ` Dave Airlie
2012-01-25 18:21 ` Thomas Hellstrom
2012-01-25 18:51 ` Jerome Glisse
2012-01-25 8:24 ` Dave Airlie
2012-01-25 8:38 ` Ben Skeggs
2012-01-25 17:32 ` Thomas Hellstrom [this message]
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=4F203CC7.4010108@shipmail.org \
--to=thomas@shipmail.org \
--cc=bskeggs@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=skeggsb@gmail.com \
/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.