Messages in this thread |  | | | From | Vitaly Mayatskikh <> | | Subject | Re: [PATCH 1/2] Introduce copy_user_handle_tail routine | | Date | Wed, 02 Jul 2008 17:32:20 +0200 |
| |
Andi Kleen <andi@firstfloor.org> writes:
>>> >> Overall you could write it much simpler with a rep ; movs I think, >>> >> like traditional linux did. >> > >> > rep movs can fail. > > How? (if it's a byte copy?)
Parameter len is a number of uncopied bytes, it doesn't count bytes which were loaded into registers before GPF in unrolled loop. copy_user_handle_tail tries to do a byte copy for, possibly, remaining bytes, but it can fail at the first read/write, or at the second, etc. It doesn't know where it will fail.
> The old 2.4 copy_*_user always used to that and it worked just fine AFAIK.
Again, Linus wanted it to be simple plain C routine. rep movs is not in C language ;)
>>> >> If zerorest is ever 0 then retesting it on every iteration seems >>> >> somewhat dumb. >> > >> > If zerorest is 0, this cycle will never be executed. > > Ok but when it's not then it will be executed on each iteration.
Ok, that's matter.
>>> >> I think a simple memset would be actually ok, i don't think we ever zero >>> >> anything that faults. That would be obviously racy anyways. If the zero >>> >> are supposed to override something then a racing user thread could always >>> >> catch it. >> > >> > Linus wanted this routine to be extremely dumb. This is the reason why tail >> > handling was moved from assembly to C. Yeah, my original patches were in >> > assembly and on the top of your realization. > > My point was that it could be simpler because zeroing should not ever fault > (copy_in_user is not supposed to zero)
Why do you think that zeroing can never fail, even in userspace? -- wbr, Vitaly
|  |