[PATCH] add NULL short circuit to fb_dealloc_cmap()

[PATCH] add NULL short circuit to fb_dealloc_cmap()

[Jesper Juhl]

Resource freeing functions should generally be safe to call with NULL pointers.
Why?
 - there is some precedence in the kernel for this for deallocation functions.
 - removes the need for callers to check pointers for NULL.
 - space is saved overall by less code to test pointers for NULL all over the place.
 - removes possible NULL pointer dereferences when a caller forgot to check.

This patch makes  fb_dealloc_cmap()  safe to call with a NULL pointer argument.


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 drivers/video/fbcmap.c |    3 +++
 1 files changed, 3 insertions(+)

--- linux-2.6.13-rc3-orig/drivers/video/fbcmap.c	2005-06-17 21:48:29.000000000 +0200
+++ linux-2.6.13-rc3/drivers/video/fbcmap.c	2005-07-17 20:33:43.000000000 +0200
@@ -130,6 +130,9 @@ fail:
 
 void fb_dealloc_cmap(struct fb_cmap *cmap)
 {
+	if (unlikely(!cmap))
+		return;
+
 	kfree(cmap->red);
 	kfree(cmap->green);
 	kfree(cmap->blue);

Re: [PATCH] add NULL short circuit to fb_dealloc_cmap()

[Jon Smirl]

On 7/17/05, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> Resource freeing functions should generally be safe to call with NULL pointers.
> Why?
>  - there is some precedence in the kernel for this for deallocation functions.
>  - removes the need for callers to check pointers for NULL.
>  - space is saved overall by less code to test pointers for NULL all over the place.
>  - removes possible NULL pointer dereferences when a caller forgot to check.
> 
> This patch makes  fb_dealloc_cmap()  safe to call with a NULL pointer argument.

The fb cmap copde would be a lot simpler if it did everything with a
single allocation instead of five. Make a super cmap struct:

struct fb_super_cmap {
   struct fb_cmap cmap;
   __u16 red[255];
   __u16 blue[255];
   __u16 green[255];
   __u16 transp[255];
}

Then adjust the code as need. Have the embedded cmap struct point to
the fields in the super_cmap and the drivers don't have to be changed.




-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH] add NULL short circuit to fb_dealloc_cmap()

[Geert Uytterhoeven]

On Sun, 17 Jul 2005, Jon Smirl wrote:
> On 7/17/05, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> > Resource freeing functions should generally be safe to call with NULL pointers.
> > Why?
> >  - there is some precedence in the kernel for this for deallocation functions.
> >  - removes the need for callers to check pointers for NULL.
> >  - space is saved overall by less code to test pointers for NULL all over the place.
> >  - removes possible NULL pointer dereferences when a caller forgot to check.
> > 
> > This patch makes  fb_dealloc_cmap()  safe to call with a NULL pointer argument.
> 
> The fb cmap copde would be a lot simpler if it did everything with a
> single allocation instead of five. Make a super cmap struct:
> 
> struct fb_super_cmap {
>    struct fb_cmap cmap;
>    __u16 red[255];
>    __u16 blue[255];
>    __u16 green[255];
>    __u16 transp[255];
                  ^^^
I assume you meant 256?

> }
> 
> Then adjust the code as need. Have the embedded cmap struct point to
> the fields in the super_cmap and the drivers don't have to be changed.

What if your colormap has more than 256 entries?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH] add NULL short circuit to fb_dealloc_cmap()

[Jan Engelhardt]

>> struct fb_super_cmap {
>>    struct fb_cmap cmap;
>>    __u16 red[255];
>>    __u16 blue[255];
>>    __u16 green[255];
>>    __u16 transp[255];
>                  ^^^
>I assume you meant 256?

Even if it really was 255, it should probably be made 256 to have things 
aligned <-- if that matters.


Jan Engelhardt
-- 

Re: [PATCH] add NULL short circuit to fb_dealloc_cmap()

[Jon Smirl]

On 7/17/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > struct fb_super_cmap {
> >    struct fb_cmap cmap;
> >    __u16 red[255];
> >    __u16 blue[255];
> >    __u16 green[255];
> >    __u16 transp[255];
>                   ^^^
> I assume you meant 256?
> 
> > }
> >
> > Then adjust the code as need. Have the embedded cmap struct point to
> > the fields in the super_cmap and the drivers don't have to be changed.
> 
> What if your colormap has more than 256 entries?

I meant 256. Does any hardware exist that takes more that 256 entries? 
They are __u16 values but I have never seen hardware that take more
that __u8 either.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH] add NULL short circuit to fb_dealloc_cmap()

[Geert Uytterhoeven]

On Sun, 17 Jul 2005, Jon Smirl wrote:
> On 7/17/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > >
> > > struct fb_super_cmap {
> > >    struct fb_cmap cmap;
> > >    __u16 red[255];
> > >    __u16 blue[255];
> > >    __u16 green[255];
> > >    __u16 transp[255];
> >                   ^^^
> > I assume you meant 256?
> > 
> > > }
> > >
> > > Then adjust the code as need. Have the embedded cmap struct point to
> > > the fields in the super_cmap and the drivers don't have to be changed.
> > 
> > What if your colormap has more than 256 entries?
> 
> I meant 256. Does any hardware exist that takes more that 256 entries? 

1024 was quite common on high-end graphics hardware.

> They are __u16 values but I have never seen hardware that take more
> that __u8 either.

10 bit was quite common on high-end graphics hardware.

IIRC, DEC TGA can do at least one of them.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds