Re: 2.6.8.1-mm4

[Alan Cox]

On Llu, 2004-08-23 at 20:40, Andrew Morton wrote:
> Noooo.  copy_*_user() returns zero on success and "number of bytes
> remaining to be copied" on fault.  The number of places in the kernel which
> actually care about the precision of the "number remaining to be copied"
> thing is very small.  Most places just test for non-zeroness.

Sorry thats what I meant to say but got it backwards. There are a lot of
users of the value actually - all the serial drivers for example use it
to get the right results. Networking too gets fun because you can send a
packet and want to report that you did something before the fault
occurred. True POSIX doesn't seem to require this behaviour (I guess it
wants to define passing bogus addresses as undefined because of MMUless
systems and library emulation of calls).

> The problem is that the current semantics are hard to implement on several
> architectures.  To get it right, sparc64 has to go back and copy one byte
> at a time just to work out the address at which the fault really occurred.

Who cares? Faults are not fast paths. Also if I understand sparc64
correctly it doesn't have to go back and copy one at a time because a
fault can only occur on a page boundary. That means for the normal case
you already know where the fault occurred and for the unusual case its
one probe per page, all non fast-path.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/