On x86-64, a put_user call using a 64-bit pointer and a constant value that
is > 0xffffffff will produce code that doesn't assemble. This patch fixes
the asm construct to use the Z constraint for 32-bit constants.
Signed-off-by: Roland McGrath <[email protected]>
---
include/asm-x86_64/uaccess.h | 70 +++++++++++++++++++++---------------------
1 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/include/asm-x86_64/uaccess.h b/include/asm-x86_64/uaccess.h
index d5dbc87..0129c79 100644
--- a/include/asm-x86_64/uaccess.h
+++ b/include/asm-x86_64/uaccess.h
@@ -157,7 +157,7 @@ do { \
case 1: __put_user_asm(x,ptr,retval,"b","b","iq",-EFAULT); break;\
case 2: __put_user_asm(x,ptr,retval,"w","w","ir",-EFAULT); break;\
case 4: __put_user_asm(x,ptr,retval,"l","k","ir",-EFAULT); break;\
- case 8: __put_user_asm(x,ptr,retval,"q","","ir",-EFAULT); break;\
+ case 8: __put_user_asm(x,ptr,retval,"q","","Zr",-EFAULT); break;\
default: __put_user_bad(); \
} \
} while (0)
On Thu, 25 Jan 2007, Roland McGrath wrote:
>
> On x86-64, a put_user call using a 64-bit pointer and a constant value that
> is > 0xffffffff will produce code that doesn't assemble. This patch fixes
> the asm construct to use the Z constraint for 32-bit constants.
Ahh. Will apply.
Just out of interest: did we have such code and it just happened to use a
register, or was this found because you wrote some new code that triggered
something that had just never been triggered before? Or is there a newer
gcc that is better at optimizations and finds a constant propagation where
it used to not find it?
Inquiring minds..
Linus
I'm not aware of any code in the tree triggering it. We copied some of the
uaccess.h macro guts into macros used in systemtap, and there we hit an
instance of someone producing code that used a large constant and hit the
problem. Since I noticed the kernel code still had the same bug, I was
just being proactive in propagating the fix back.
Thanks,
Roland