[patch] staging: gma500: fix some swapped gotos

[patch] staging: gma500: fix some swapped gotos

[Dan Carpenter]

These gotos were swapped.  In the original code, the first would result
in a NULL dereference and the second would result in a memory leak.

Signed-off-by: Dan Carpenter <error27@gmail.com>

diff --git a/drivers/staging/gma500/psb_fb.c b/drivers/staging/gma500/psb_fb.c
index 6585e88..9f4b570 100644
--- a/drivers/staging/gma500/psb_fb.c
+++ b/drivers/staging/gma500/psb_fb.c
@@ -458,7 +458,7 @@ static int psbfb_create(struct psb_fbdev *fbdev,
 	if (!fb) {
 		DRM_ERROR("failed to allocate fb.\n");
 		ret = -ENOMEM;
-		goto out_err0;
+		goto out_err1;
 	}
 	psbfb = to_psb_fb(fb);
 	psbfb->size = size;
@@ -466,7 +466,7 @@ static int psbfb_create(struct psb_fbdev *fbdev,
 	info = framebuffer_alloc(sizeof(struct psb_fbdev), device);
 	if (!info) {
 		ret = -ENOMEM;
-		goto out_err1;
+		goto out_err0;
 	}
 
 	info->par = fbdev;

Re: [patch] staging: gma500: fix some swapped gotos

[Alan Cox]

On Sat, 26 Feb 2011 15:48:12 +0300
Dan Carpenter <error27@gmail.com> wrote:

> These gotos were swapped.  In the original code, the first would
> result in a NULL dereference and the second would result in a memory
> leak.
> 
> Signed-off-by: Dan Carpenter <error27@gmail.com>

Applied to my GMA500 tree. Need to sort out with GregKH how we handle
stuff in general though as it seems that staging may not work for this
driver due to the rate of change in the DRM tree.

Alan

Re: [patch] staging: gma500: fix some swapped gotos

[Greg KH]

On Tue, Mar 01, 2011 at 01:50:23PM +0000, Alan Cox wrote:
> On Sat, 26 Feb 2011 15:48:12 +0300
> Dan Carpenter <error27@gmail.com> wrote:
> 
> > These gotos were swapped.  In the original code, the first would
> > result in a NULL dereference and the second would result in a memory
> > leak.
> > 
> > Signed-off-by: Dan Carpenter <error27@gmail.com>
> 
> Applied to my GMA500 tree. Need to sort out with GregKH how we handle
> stuff in general though as it seems that staging may not work for this
> driver due to the rate of change in the DRM tree.

I've already applied this to my tree.

And yeah, I'm wondering if this makes sense to go through me, as you are
going to be depending on drm changes.  Perhaps you want to push it
through there instead for the initial merge?

thanks,

greg k-h