All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
To: Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
Date: Wed, 04 Sep 2013 08:59:13 +0200	[thread overview]
Message-ID: <5226DA41.5060203@canonical.com> (raw)
In-Reply-To: <CACAvsv7ygYoM6ZzFdY-Zov0herPMQDERaw6jzj6VuB+p20FcJQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Op 04-09-13 05:41, Ben Skeggs schreef:
> On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
> <maarten.lankhorst-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
>> Op 22-08-13 02:10, Ilia Mirkin schreef:
>>> The code expects non-VRAM mem nodes to have a pages list. If that's not
>>> set, it will do a null deref down the line. Warn on that condition and
>>> return an error.
>>>
>>> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
>>>
>>> Reported-by: Pasi Kärkkäinen <pasik-X3B1VOXEql0@public.gmane.org>
>>> Tested-by: Pasi Kärkkäinen <pasik-X3B1VOXEql0@public.gmane.org>
>>> Signed-off-by: Ilia Mirkin <imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
>>> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # 3.8+
>>> ---
>>>
>>> I don't exactly understand what's going on, but this is just a
>>> straightforward way to avoid a null deref that you see happens in the
>>> bug. I haven't figured out the root cause of this, but it's getting
>>> well into the "I have no idea how TTM works" space. However this seems
>>> like a bit of defensive programming -- nouveau_vm_map_sg will pass
>>> node->pages as a list down, which will be dereferenced by
>>> nvc0_vm_map_sg. Perhaps the other arguments should make that
>>> dereferencing not happen, but it definitely was happening here, as you
>>> can see in the bug.
>>>
>>> Ben/Maarten, I'll let you judge whether this check is appropriate,
>>> since like I hope I was able to convey above, I'm just not really sure :)
>> Not it really isn't appropriate..
>>
>> You'd have to call call nouveau_vm_map_sg_table instead, the only place that doesn't handle that correctly
>> is where it's not expected to be called.
>>
>> Here, have a completely untested patch to fix things...
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c
>> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
>> @@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
>>  {
>>         struct nouveau_framebuffer *nouveau_fb;
>>         struct drm_gem_object *gem;
>> +       struct nouveau_bo *nvbo;
>>         int ret = -ENOMEM;
>>
>>         gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
>>         if (!gem)
>>                 return ERR_PTR(-ENOENT);
>>
>> +       nvbo = nouveau_gem_object(gem);
>> +       if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
>> +               nv_warn(nouveau_drm(dev), "Trying to create a fb in vram with"
>> +                       " valid_domains=%08x\n", nvbo->valid_domains);
>> +               ret = -EINVAL;
>> +               goto err_unref;
>> +       }
>> +
> Definitely the right idea, we can't handle this case right now.
> However, we may someday want/need to be able to scan out of system
> memory, so this is the wrong place.
>
> I suspect the correct thing to do (which'll also handle the
> "defensive" part) is to bail in nouveau_bo_move() on attempts to move
> a DMA-BUF backed object into VRAM.
>
> Sound OK?
>
If it has a WARN_ON or something that would be ok, I didn't find any other places that attempt to move buffers to VRAM though, so it's probably harmless.

When looking into this bug I noticed that nouveau_bo_vma_add needs to have a check for nvbo->page_shift == vma->vm->vmm->spg_shift,
and only if the check is true it should map the page in TTM_PL_TT. Patch below.
Should probably also be cc'd to stable.

~Maarten

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 89b992e..355a1b7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1560,7 +1560,8 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct nouveau_vm *vm,
 
 	if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
 		nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
-	else if (nvbo->bo.mem.mem_type == TTM_PL_TT) {
+	else if (nvbo->bo.mem.mem_type == TTM_PL_TT &&
+		 nvbo->page_shift == vma->vm->vmm->spg_shift) {
 		if (node->sg)
 			nouveau_vm_map_sg_table(vma, 0, size, node);
 		else

  parent reply	other threads:[~2013-09-04  6:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-22  0:10 [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap Ilia Mirkin
2013-08-22  6:41 ` Ben Skeggs
     [not found]   ` <CACAvsv4zNrgnBkaJOJyDyDq1bnW37eccjsT=c4yfBJHcNgaaWQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-22  6:54     ` Pasi Kärkkäinen
2013-08-22  7:12 ` Maarten Lankhorst
     [not found]   ` <5215B9E8.5080108-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2013-08-22  7:58     ` Pasi Kärkkäinen
2013-08-23 20:20   ` Pasi Kärkkäinen
     [not found]     ` <20130823202042.GS2924-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
2013-08-28  6:29       ` Pasi Kärkkäinen
     [not found]         ` <20130828062948.GE2924-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
2013-08-28  7:44           ` Maarten Lankhorst
2013-09-03 14:20             ` Pasi Kärkkäinen
2013-09-03 14:34               ` Maarten Lankhorst
2013-09-03 14:48                 ` Pasi Kärkkäinen
2013-09-03 17:58                   ` Pasi Kärkkäinen
2013-09-04  3:41   ` Ben Skeggs
     [not found]     ` <CACAvsv7ygYoM6ZzFdY-Zov0herPMQDERaw6jzj6VuB+p20FcJQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-09-04  6:59       ` Maarten Lankhorst [this message]
2013-09-10 10:39         ` Pasi Kärkkäinen
2013-09-25 14:41         ` Pasi Kärkkäinen
2013-09-25 16:48           ` Ben Skeggs
2013-09-25 16:53             ` Pasi Kärkkäinen
2013-10-18 14:44             ` Pasi Kärkkäinen
     [not found]               ` <20131018144445.GP2924-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
2014-01-03 18:32                 ` Pasi Kärkkäinen
2013-09-25 14:42         ` Pasi Kärkkäinen
2013-10-18 14:45           ` Pasi Kärkkäinen

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=5226DA41.5060203@canonical.com \
    --to=maarten.lankhorst-z7wlfzj8ewms+fvcfc7uqw@public.gmane.org \
    --cc=bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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.