Messages in this thread | | | Date | Wed, 02 Jul 2008 20:54:36 +0200 | From | Andi Kleen <> | Subject | Re: [PATCH 1/2] Introduce copy_user_handle_tail routine |
| |
Vitaly Mayatskikh wrote: > Andi Kleen <andi@firstfloor.org> writes: > >>>>>> rep movs can fail. >>>> How? (if it's a byte copy?) >>> Parameter len is a number of uncopied bytes, >> But that is exactly what copy_*_user wants to return > > Last experience showed, it doesn't.
?
> Ok, when unrolled version fails on reading quad word at unaligned > address, it doesn't know where it was failed exactly. At this moment it > hasn't correct number of uncopied bytes, because some bytes can still > remain at the very end of the page. copy_user_handle_tail copies them > and return correct value on uncopied bytes. Complicated logic for > counting the number of these bytes is not necessary to optimize at > assembly level, because we already missed performance. It's hard to > complain against it.
Yes I'm talking about the "replay loop"
There's no complicated logic in a rep ; movs. And it's still a byte copy. In fact it is far simpler than what you already have.
>> The original version I wrote returned "unfaulted bytes" which was wrong. >> Correct is "uncopied" as fixed by Linus. rep ; movs returns uncopied. > > It's not in C. If you have the proposal why it should be written in > assembly, send it to Linus.
Well it would turn your 15+ lines C function in ~4 (well tested) lines or so.
> >>> Why do you think that zeroing can never fail, even in userspace? >> There's no zeroing in user space, only in kernel space. > > Agree. > >> The only reason kernel does it is to avoid leaking uninitialized data, >> but for user space it doesn't make sense (see above) > > Ok, copy_in_user can pass zerorest=0 to copy_user_handle_tail. Is it ok > for you?
My point was that for the zeroing you can just use memset(), there's no need to support faulting there at all.
-Andi
| |