Re: [PATCH][FBDEV] Fix copy_to/from_user in fbmem.c:fb_read/write

[Andrew Morton <akpm@osdl.org>]

Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> > +
>  > +	cnt = 0;
>  > +	buffer = kmalloc((count > 64 * 1024) ? 64 * 1024 : count,
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  > +			 GFP_KERNEL);
>  > +	if (!buffer)
>  > +		return -ENOMEM;
> 
>  Woops, what's the probability of a 64 kiB kmalloc() to fail?

Relatively high.

>      [...]
> 
>  > +	while (count) {
>  > +		c  = (count > 64 * 1024) ? 64 * 1024 : count;
>  > +		dst = buffer;
>  > +		for (i = c >> 2; i--; )
>  > +			*dst++ = fb_readl(src++);
>  > +		if (c & 3) {
>  > +			for (i = c & 3; i--;)
>  > +				*((u8 *)dst++) = fb_readb((u8 *) src++);
>  > +		}
>  > +
>  > +		if (copy_to_user(buf, buffer, c)) {
>  > +			err = -EFAULT;
>  > +			break;
>  > +		}
>  > +		*ppos += c;
>  > +		buf += c;
>  > +		cnt += c;
>  > +		count -= c;
>  >  	}
> 
>  I don't expect the penalty for always using a buffer of PAGE_SIZE to be very
>  large. Or am I missing something?

The 64k copy buffer will most likely be slower than using an 8k one.  it
depends, of course, upon the vintage of the CPU.

4k or 8k should be fine here.


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click