All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stefan Lippers-Hollmann" <s.L-H@gmx.de>
To: gregkh@suse.de
Cc: linux-kernel@vger.kernel.org, suokkos@gmail.com,
	airlied@redhat.com, stable@kernel.org
Subject: Re: patch drm-radeon-kms-fix-null-pointer-dereference-if-memory-allocation-failed.patch added to 2.6.33-stable tree
Date: Tue, 6 Apr 2010 23:45:38 +0200	[thread overview]
Message-ID: <201004062345.40988.s.L-H@gmx.de> (raw)
In-Reply-To: <1270231240946@site>

Hi

On Tuesday 06 April 2010, gregkh@suse.de wrote:
> This is a note to let you know that we have just queued up the patch titled
> 
>     Subject: drm/radeon/kms: Fix NULL pointer dereference if memory allocation failed.
> 
> to the 2.6.33-stable tree.  Its filename is
> 
>     drm-radeon-kms-fix-null-pointer-dereference-if-memory-allocation-failed.patch
> 
> A git repo of this tree can be found at 
>     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> 
> 
> From fcbc451ba1948fba967198bd150ecbd10bbb7075 Mon Sep 17 00:00:00 2001
> From: Pauli Nieminen <suokkos@gmail.com>
> Date: Fri, 19 Mar 2010 07:44:33 +0000
> Subject: drm/radeon/kms: Fix NULL pointer dereference if memory allocation failed.
> 
> From: Pauli Nieminen <suokkos@gmail.com>
> 
> commit fcbc451ba1948fba967198bd150ecbd10bbb7075 upstream.
> 
> When there is allocation failure in radeon_cs_parser_relocs parser->nrelocs
> is not cleaned. This causes NULL pointer defeference in radeon_cs_parser_fini
> when clean up code is trying to loop over the relocation array and free the
> objects.
> 
> Fix adds a check for a possible NULL pointer in clean up code.
[...]

This patch breaks compiling kernel 2.6.33 + the current stable queue:

  CC [M]  drivers/gpu/drm/radeon/radeon_cs.o
/tmp/buildd/linux-sidux-2.6-2.6.33/debian/build/source_amd64_none/drivers/gpu/drm/radeon/radeon_cs.c: In function 'radeon_cs_parser_fini':
/tmp/buildd/linux-sidux-2.6-2.6.33/debian/build/source_amd64_none/drivers/gpu/drm/radeon/radeon_cs.c:200: error: implicit declaration of function 'drm_gem_object_unreference_unlocked'
make[6]: *** [drivers/gpu/drm/radeon/radeon_cs.o] Error 1

as it depends on the introduction of drm_gem_object_unreference_unlocked()
in:

Commit:     c3ae90c099bb62387507e86da7cf799850444b08
Author:     Luca Barbieri <luca@luca-barbieri.com>
AuthorDate: Tue Feb 9 05:49:11 2010 +0000

    drm: introduce drm_gem_object_[handle_]unreference_unlocked
    
    This patch introduces the drm_gem_object_unreference_unlocked
    and drm_gem_object_handle_unreference_unlocked functions that
    do not require holding struct_mutex.
    
    drm_gem_object_unreference_unlocked calls the new
    ->gem_free_object_unlocked entry point if available, and
    otherwise just takes struct_mutex and just calls ->gem_free_object

which in turn suggests:

Commit:     bc9025bdc4e2b591734cca17697093845007b63d
Author:     Luca Barbieri <luca@luca-barbieri.com>
AuthorDate: Tue Feb 9 05:49:12 2010 +0000

    Use drm_gem_object_[handle_]unreference_unlocked where possible
    
    Mostly obvious simplifications.
    
    The i915 pread/pwrite ioctls, intel_overlay_put_image and
    nouveau_gem_new were incorrectly using the locked versions
    without locking: this is also fixed in this patch.

which don't really look like candidates for 2.6.33-stable.

> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -193,11 +193,13 @@ static void radeon_cs_parser_fini(struct
>  		radeon_bo_list_fence(&parser->validated, parser->ib->fence);
>  	}
>  	radeon_bo_list_unreserve(&parser->validated);
> -	for (i = 0; i < parser->nrelocs; i++) {
> -		if (parser->relocs[i].gobj) {
> -			mutex_lock(&parser->rdev->ddev->struct_mutex);
> -			drm_gem_object_unreference(parser->relocs[i].gobj);
> -			mutex_unlock(&parser->rdev->ddev->struct_mutex);
> +	if (parser->relocs != NULL) {
   	^ the only important part, the rest merely covers the new indentation 
  	  level

> +		for (i = 0; i < parser->nrelocs; i++) {
> +			if (parser->relocs[i].gobj) {
> +				mutex_lock(&parser->rdev->ddev->struct_mutex);
> +				drm_gem_object_unreference_unlocked(parser->relocs[i].gobj);
  				^ drm_gem_object_unreference_unlocked() doesn't exist in 2.6.33, yet
  				  we can use drm_gem_object_unreference() instead.

> +				mutex_unlock(&parser->rdev->ddev->struct_mutex);
> +			}
>  		}
>  	}
>  	kfree(parser->track);

As a consequence, I'd suggest to merely backport the NULL pointer check,
while ignoring the simplification of using the newly introduced 
drm_gem_object_unreference_unlocked() from 2.6.34:

Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>

--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -193,11 +193,13 @@ static void radeon_cs_parser_fini(struct
 		radeon_bo_list_fence(&parser->validated, parser->ib->fence);
 	}
 	radeon_bo_list_unreserve(&parser->validated);
-	for (i = 0; i < parser->nrelocs; i++) {
-		if (parser->relocs[i].gobj) {
-			mutex_lock(&parser->rdev->ddev->struct_mutex);
-			drm_gem_object_unreference(parser->relocs[i].gobj);
-			mutex_unlock(&parser->rdev->ddev->struct_mutex);
+	if (parser->relocs != NULL) {
+		for (i = 0; i < parser->nrelocs; i++) {
+			if (parser->relocs[i].gobj) {
+				mutex_lock(&parser->rdev->ddev->struct_mutex);
+				drm_gem_object_unreference(parser->relocs[i].gobj);
+				mutex_unlock(&parser->rdev->ddev->struct_mutex);
+			}
 		}
 	}
 	kfree(parser->track);

       reply	other threads:[~2010-04-06 21:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1270231240946@site>
2010-04-06 21:45 ` Stefan Lippers-Hollmann [this message]
2010-04-06 23:40   ` patch drm-radeon-kms-fix-null-pointer-dereference-if-memory-allocation-failed.patch added to 2.6.33-stable tree Greg KH

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=201004062345.40988.s.L-H@gmx.de \
    --to=s.l-h@gmx.de \
    --cc=airlied@redhat.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@kernel.org \
    --cc=suokkos@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.