RE: [PATCH] x86/uaccess: fix code generation in put_user()

2020-10-24 Thread David Laight
From: David Laight > Sent: 23 October 2020 22:52 ... > Could do_put_user() do an initial check for 64 bit > then expand a different #define that contains the actual > code passing either "a" or "A" for the constriant. > > Apart from another level of indirection nothing is duplicated. This code

RE: [PATCH] x86/uaccess: fix code generation in put_user()

2020-10-23 Thread hpa
On October 23, 2020 2:52:16 PM PDT, David Laight wrote: >From: Linus Torvalds >> Sent: 23 October 2020 22:11 >> >> On Fri, Oct 23, 2020 at 2:00 PM wrote: >> > >> > There is no same reason to mess around with hacks when we are >talking about dx:ax, though. >> >> Sure there is. >> >> "A"

Re: [PATCH] x86/uaccess: fix code generation in put_user()

2020-10-23 Thread hpa
On October 23, 2020 2:11:19 PM PDT, Linus Torvalds wrote: >On Fri, Oct 23, 2020 at 2:00 PM wrote: >> >> There is no same reason to mess around with hacks when we are talking >about dx:ax, though. > >Sure there is. > >"A" doesn't actually mean %edx:%eax like you seem to think. > >It actually

RE: [PATCH] x86/uaccess: fix code generation in put_user()

2020-10-23 Thread David Laight
From: Linus Torvalds > Sent: 23 October 2020 22:11 > > On Fri, Oct 23, 2020 at 2:00 PM wrote: > > > > There is no same reason to mess around with hacks when we are talking about > > dx:ax, though. > > Sure there is. > > "A" doesn't actually mean %edx:%eax like you seem to think. > > It

Re: [PATCH] x86/uaccess: fix code generation in put_user()

2020-10-23 Thread Linus Torvalds
On Fri, Oct 23, 2020 at 2:00 PM wrote: > > There is no same reason to mess around with hacks when we are talking about > dx:ax, though. Sure there is. "A" doesn't actually mean %edx:%eax like you seem to think. It actually means %eax OR %edx, and then if given a 64-bit value, it will use the

Re: [PATCH] x86/uaccess: fix code generation in put_user()

2020-10-23 Thread hpa
On October 23, 2020 1:55:22 PM PDT, Linus Torvalds wrote: >Thanks, applied. > >On Fri, Oct 23, 2020 at 1:32 PM Rasmus Villemoes > wrote: >> >> I'm wondering if one would also need to make __ptr_pu and __ret_pu >> explicitly "%"_ASM_CX". > >No, the "c"/"0" thing is much better, and makes it

Re: [PATCH] x86/uaccess: fix code generation in put_user()

2020-10-23 Thread Linus Torvalds
Thanks, applied. On Fri, Oct 23, 2020 at 1:32 PM Rasmus Villemoes wrote: > > I'm wondering if one would also need to make __ptr_pu and __ret_pu > explicitly "%"_ASM_CX". No, the "c"/"0" thing is much better, and makes it properly atomic wrt the actual asm. As mentioned to Andy, the "register

Re: [PATCH] x86/uaccess: fix code generation in put_user()

2020-10-23 Thread hpa
On October 23, 2020 1:42:39 PM PDT, Andy Lutomirski wrote: >On Fri, Oct 23, 2020 at 1:32 PM Rasmus Villemoes > wrote: >> >> Quoting >> https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html: >> >> You can define a local register variable and associate it with a >> specified

Re: [PATCH] x86/uaccess: fix code generation in put_user()

2020-10-23 Thread Linus Torvalds
On Fri, Oct 23, 2020 at 1:42 PM Andy Lutomirski wrote: > > This looks like the patch is an improvement, but this is still IMO > likely to be very fragile. Can we just do the size-dependent "a" vs > "A" selection method instead? Sure, it's a little more code, but it > will be Obviously Correct.

Re: [PATCH] x86/uaccess: fix code generation in put_user()

2020-10-23 Thread Andy Lutomirski
On Fri, Oct 23, 2020 at 1:32 PM Rasmus Villemoes wrote: > > Quoting > https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html: > > You can define a local register variable and associate it with a > specified register... > > The only supported use for this feature is to specify

[PATCH] x86/uaccess: fix code generation in put_user()

2020-10-23 Thread Rasmus Villemoes
Quoting https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html: You can define a local register variable and associate it with a specified register... The only supported use for this feature is to specify registers for input and output operands when calling Extended asm (see