Re: Followup: copy_to_user return value breaks lots of code

Andi Kleen (ak@muc.de)
23 Jan 1998 22:19:30 +0100


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