lkml.org 
[lkml]   [1998]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Followup: copy_to_user return value breaks lots of code
From
Date
Michael Elizabeth Chastain <mec@shout.net> writes:

> Hi Linus and everyone,
>
> I spoke too soon. My first analysis was buggy but there are still
> two real problems here.
>
> For reference, in 2.1.80, the call tree is:
>
> copy_to_user
> __constant_copy_to_user
> access_ok
> __copy_user
> __generic_copy_to_user
>
> Problem #1:
> __generic_copy_to_user is a true function so it can't alter its
> arguments. Thus it returns the original number of bytes requested.

I don't see this problem. The old __generic_copy_to_user was an inline
function, and inline functions have the same calling conventions as real
functions.


> Problem #2:
> A lot of code does this:
> return copy_to_user(..., ..., ...);
> This code thinks it's going to return -EFAULT, but it isnt't.

This code is just buggy. Please reread the kernel mailing list
archives for the reasoning behind the return value (personally I'm not
sure if it is really enough reason for the complicated interface, but
Linus has decided so we have it now this way)

> include/asm-i386/uaccess.h needs to spell out which macros are meant
> to be used (as opposed to internal-only macros), and it needs to specify
> the exact return values for all input conditions.

This would be a good idea. Feel free to submit patches.


-Andi


\
 
 \ /
  Last update: 2005-03-22 13:41    [from the cache]
©2003-2011 Jasper Spaans