[PATCH] x86_64: fix put_user for 64-bit constant

[PATCH] x86_64: fix put_user for 64-bit constant

[Roland McGrath]

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 <roland@redhat.com>
---
 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)

Re: [PATCH] x86_64: fix put_user for 64-bit constant

[Linus Torvalds]

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

Re: [PATCH] x86_64: fix put_user for 64-bit constant

[Roland McGrath]

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