Nouveau Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Pasi Kärkkäinen" <pasik@iki.fi>
To: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: "nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Ben Skeggs <bskeggs@redhat.com>
Subject: Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
Date: Tue, 10 Sep 2013 13:39:14 +0300	[thread overview]
Message-ID: <20130910103914.GL2924@reaktio.net> (raw)
In-Reply-To: <5226DA41.5060203@canonical.com>

On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote:
> Op 04-09-13 05:41, Ben Skeggs schreef:
> > On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
> > <maarten.lankhorst@canonical.com> 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@iki.fi>
> >>> Tested-by: Pasi Kärkkäinen <pasik@iki.fi>
> >>> Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
> >>> Cc: <stable@vger.kernel.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.
> 

So hmm.. I guess another patch is needed for the original issue in this thread.
Is someone going to submit that? 


> 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.
>

Thanks! Is this patch ready to be merged?


-- Pasi
 

> ~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
> 

  reply	other threads:[~2013-09-10 10:39 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
2013-09-10 10:39         ` Pasi Kärkkäinen [this message]
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=20130910103914.GL2924@reaktio.net \
    --to=pasik@iki.fi \
    --cc=bskeggs@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=maarten.lankhorst@canonical.com \
    --cc=nouveau@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