nios2: __kuser_sigtramp placement fix

PATCH In review Chung-Lin Tang 3 participants 6 messages Jan 22, 2015 NIOS2 architecture

Share & tools

Chung-Lin Tang

author

2015-01-22 07:14 UTC #0 lore raw

PATCH 1/1 nios2: __kuser_sigtramp placement fix

The address of __kuser_sigtramp is wrong by one word, due to padding __kuser_cmpxchg to fully 64 bytes. The version word at the start of the page displaces __kuser_sigtramp to 0x1044, instead of the intended 0x1040.

Fixed by counting the 64-byte frame from the start of the page instead of __kuser_cmpxchg. This shortens the __kuser_cmpxchg frame to 60-bytes, but that's likely enough.

The zero-byte padding parts of the kuser_pad macro has been removed, due to the .if command refusing to behave properly when there are other .word directives in between. Probably a binutils gas bug.

Thanks,
Chung-Lin

Cc Ley Foon Tan <[email protected]>

Cc Tobias Klauser <[email protected]>

Signed-off-by Chung-Lin Tang <[email protected]>

arch/nios2/kernel/entry.S +5 -9

index 0bdfd13..3224839 100644
@@ -492,14 +492,7 @@ ENTRY(ret_from_kernel_thread)
 
  /* Filling pads with undefined instructions. */
 .macro	kuser_pad sym size
-	.if	((. - \sym) & 3)
-	.rept	(4 - (. - \sym) & 3)
-	.byte	0
-	.endr
-	.endif
-	.rept	((\size - (. - \sym)) / 4)
-	.word	0xdeadbeef
-	.endr
+	.fill	((\size - (. - \sym)) / 4), 4, 0xdeadbeef
 .endm
 
 	.align	6

@@ -526,7 +519,10 @@ cmpxchg_stw:
 cmpxchg_ret:
 	ret
 
-	kuser_pad __kuser_cmpxchg, 64
+	/* The first 64-byte frame contains the version word, so note
+	   that the first padding entry is based from the start of the kuser
+	   page, instead of __kuser_cmpxchg.  */
+	kuser_pad __kuser_helper_start, 64
 
 	.globl	__kuser_sigtramp
 __kuser_sigtramp:

Ley Foon Tan

2015-01-22 07:54 UTC #1 lore raw

Quoted 42 lines · Chung-Lin Tang

The address of __kuser_sigtramp is wrong by one word, due to padding __kuser_cmpxchg to fully 64 bytes. The version word at the start of the page displaces __kuser_sigtramp to 0x1044, instead of the intended 0x1040.
Fixed by counting the 64-byte frame from the start of the page instead of __kuser_cmpxchg. This shortens the __kuser_cmpxchg frame to 60-bytes, but that's likely enough.
The zero-byte padding parts of the kuser_pad macro has been removed, due to the .if command refusing to behave properly when there are other .word directives in between. Probably a binutils gas bug.
Thanks,
Chung-Lin
Cc Ley Foon Tan <[email protected]>
Cc Tobias Klauser <[email protected]>
Signed-off-by Chung-Lin Tang <[email protected]>
arch/nios2/kernel/entry.S +1 -8
index 0bdfd13..3224839 100644
@@ -492,14 +492,7 @@ ENTRY(ret_from_kernel_thread)
 
  /* Filling pads with undefined instructions. */
 .macro kuser_pad sym size
-       .if     ((. - \sym) & 3)
-       .rept   (4 - (. - \sym) & 3)
-       .byte   0
-       .endr
-       .endif
-       .rept   ((\size - (. - \sym)) / 4)
-       .word   0xdeadbeef
-       .endr
+       .fill   ((\size - (. - \sym)) / 4), 4, 0xdeadbeef
 .endm
 
        .align  6
@@ -526,7 +519,10 @@ cmpxchg_stw:
 cmpxchg_ret:
        ret

arch/nios2/kernel/entry.S cmpxchg_stw:

Quoted 10 lines

arch/nios2/kernel/entry.S +4 -2

 
-       kuser_pad __kuser_cmpxchg, 64
+       /* The first 64-byte frame contains the version word, so note
+          that the first padding entry is based from the start of the kuser
+          page, instead of __kuser_cmpxchg.  */
+       kuser_pad __kuser_helper_start, 64
 
        .globl  __kuser_sigtramp
 __kuser_sigtramp:
--

Hi Chung-Lin

I thought this is our original intention for it.

First 4 bytes is the __kuser_version and each __kuser function will have 64 bytes size.

0x1000 __kuser_helper_version
0x1004 __kuser_cmpxchg
0x1044 __kuser_sigtramp

Any reason you can't use __kuser_sigtramp @ 0x1044? Thanks.

Regards
Ley Foon

Chung-Lin Tang

2015-01-22 08:15 UTC #2 lore raw

Quoted 57 lines · Ley Foon Tan

Quoted 42 lines · Chung-Lin Tang
The address of __kuser_sigtramp is wrong by one word, due to padding __kuser_cmpxchg to fully 64 bytes. The version word at the start of the page displaces __kuser_sigtramp to 0x1044, instead of the intended 0x1040.
Fixed by counting the 64-byte frame from the start of the page instead of __kuser_cmpxchg. This shortens the __kuser_cmpxchg frame to 60-bytes, but that's likely enough.
The zero-byte padding parts of the kuser_pad macro has been removed, due to the .if command refusing to behave properly when there are other .word directives in between. Probably a binutils gas bug.
Thanks,
Chung-Lin
Cc Ley Foon Tan <[email protected]>
Cc Tobias Klauser <[email protected]>
Signed-off-by Chung-Lin Tang <[email protected]>
arch/nios2/kernel/entry.S +1 -8
index 0bdfd13..3224839 100644
@@ -492,14 +492,7 @@ ENTRY(ret_from_kernel_thread)
 
  /* Filling pads with undefined instructions. */
 .macro kuser_pad sym size
-       .if     ((. - \sym) & 3)
-       .rept   (4 - (. - \sym) & 3)
-       .byte   0
-       .endr
-       .endif
-       .rept   ((\size - (. - \sym)) / 4)
-       .word   0xdeadbeef
-       .endr
+       .fill   ((\size - (. - \sym)) / 4), 4, 0xdeadbeef
 .endm
 
        .align  6
@@ -526,7 +519,10 @@ cmpxchg_stw:
 cmpxchg_ret:
        ret
arch/nios2/kernel/entry.S cmpxchg_stw:
Quoted 10 lines
arch/nios2/kernel/entry.S +4 -2
 
-       kuser_pad __kuser_cmpxchg, 64
+       /* The first 64-byte frame contains the version word, so note
+          that the first padding entry is based from the start of the kuser
+          page, instead of __kuser_cmpxchg.  */
+       kuser_pad __kuser_helper_start, 64
 
        .globl  __kuser_sigtramp
 __kuser_sigtramp:
--
Hi Chung-Lin
I thought this is our original intention for it.

Quoted 8 lines

First 4 bytes is the __kuser_version and each __kuser function will have 64 bytes size.
0x1000 __kuser_helper_version
0x1004 __kuser_cmpxchg
0x1044 __kuser_sigtramp
Any reason you can't use __kuser_sigtramp @ 0x1044?

Well, that's okay as well, as the main place which sets this is the signal frame construction in arch/nios2/kernel/signal.c. The user space is mostly oblivious to the exact location. You'll need to update it that way if you prefer 0x1044, as it's currently set at 0x1040.

I suggested 0x1040 because 64b frames aligned at 64b seemed more intuitive; __kuser_cmpxchg would be a special case.

Chung-Lin

Ley Foon Tan

2015-01-22 08:43 UTC #3 lore raw

Quoted 67 lines · Chung-Lin Tang

Quoted 57 lines · Ley Foon Tan
Quoted 42 lines · Chung-Lin Tang
The address of __kuser_sigtramp is wrong by one word, due to padding __kuser_cmpxchg to fully 64 bytes. The version word at the start of the page displaces __kuser_sigtramp to 0x1044, instead of the intended 0x1040.
Fixed by counting the 64-byte frame from the start of the page instead of __kuser_cmpxchg. This shortens the __kuser_cmpxchg frame to 60-bytes, but that's likely enough.
The zero-byte padding parts of the kuser_pad macro has been removed, due to the .if command refusing to behave properly when there are other .word directives in between. Probably a binutils gas bug.
Thanks,
Chung-Lin
Cc Ley Foon Tan <[email protected]>
Cc Tobias Klauser <[email protected]>
Signed-off-by Chung-Lin Tang <[email protected]>
arch/nios2/kernel/entry.S +1 -8
index 0bdfd13..3224839 100644
@@ -492,14 +492,7 @@ ENTRY(ret_from_kernel_thread)
 
  /* Filling pads with undefined instructions. */
 .macro kuser_pad sym size
-       .if     ((. - \sym) & 3)
-       .rept   (4 - (. - \sym) & 3)
-       .byte   0
-       .endr
-       .endif
-       .rept   ((\size - (. - \sym)) / 4)
-       .word   0xdeadbeef
-       .endr
+       .fill   ((\size - (. - \sym)) / 4), 4, 0xdeadbeef
 .endm
 
        .align  6
@@ -526,7 +519,10 @@ cmpxchg_stw:
 cmpxchg_ret:
        ret
arch/nios2/kernel/entry.S cmpxchg_stw:
Quoted 10 lines
arch/nios2/kernel/entry.S +4 -2
 
-       kuser_pad __kuser_cmpxchg, 64
+       /* The first 64-byte frame contains the version word, so note
+          that the first padding entry is based from the start of the kuser
+          page, instead of __kuser_cmpxchg.  */
+       kuser_pad __kuser_helper_start, 64
 
        .globl  __kuser_sigtramp
 __kuser_sigtramp:
--
Hi Chung-Lin
I thought this is our original intention for it.
Quoted 8 lines
First 4 bytes is the __kuser_version and each __kuser function will have 64 bytes size.
0x1000 __kuser_helper_version
0x1004 __kuser_cmpxchg
0x1044 __kuser_sigtramp
Any reason you can't use __kuser_sigtramp @ 0x1044?

Quoted 7 lines

Well, that's okay as well, as the main place which sets this is the signal frame construction in arch/nios2/kernel/signal.c. The user space is mostly oblivious to the exact location. You'll need to update it that way if you prefer 0x1044, as it's currently set at 0x1040.
I suggested 0x1040 because 64b frames aligned at 64b seemed more intuitive; __kuser_cmpxchg would be a special case.

I think I will change to 0x1044 in arch/nios2/kernel/signal.c. I can submit the fix.
Do you need to update toolchain for this change?

Regards
Ley Foon

Chung-Lin Tang

2015-01-22 09:07 UTC #4 lore raw

Quoted 73 lines · Ley Foon Tan

Quoted 72 lines · Chung-Lin Tang
Quoted 57 lines · Ley Foon Tan
Quoted 42 lines · Chung-Lin Tang
The address of __kuser_sigtramp is wrong by one word, due to padding __kuser_cmpxchg to fully 64 bytes. The version word at the start of the page displaces __kuser_sigtramp to 0x1044, instead of the intended 0x1040.
Fixed by counting the 64-byte frame from the start of the page instead of __kuser_cmpxchg. This shortens the __kuser_cmpxchg frame to 60-bytes, but that's likely enough.
The zero-byte padding parts of the kuser_pad macro has been removed, due to the .if command refusing to behave properly when there are other .word directives in between. Probably a binutils gas bug.
Thanks,
Chung-Lin
Cc Ley Foon Tan <[email protected]>
Cc Tobias Klauser <[email protected]>
Signed-off-by Chung-Lin Tang <[email protected]>
arch/nios2/kernel/entry.S +1 -8
index 0bdfd13..3224839 100644
@@ -492,14 +492,7 @@ ENTRY(ret_from_kernel_thread)
 
  /* Filling pads with undefined instructions. */
 .macro kuser_pad sym size
-       .if     ((. - \sym) & 3)
-       .rept   (4 - (. - \sym) & 3)
-       .byte   0
-       .endr
-       .endif
-       .rept   ((\size - (. - \sym)) / 4)
-       .word   0xdeadbeef
-       .endr
+       .fill   ((\size - (. - \sym)) / 4), 4, 0xdeadbeef
 .endm
 
        .align  6
@@ -526,7 +519,10 @@ cmpxchg_stw:
 cmpxchg_ret:
        ret
arch/nios2/kernel/entry.S cmpxchg_stw:
Quoted 10 lines
arch/nios2/kernel/entry.S +4 -2
 
-       kuser_pad __kuser_cmpxchg, 64
+       /* The first 64-byte frame contains the version word, so note
+          that the first padding entry is based from the start of the kuser
+          page, instead of __kuser_cmpxchg.  */
+       kuser_pad __kuser_helper_start, 64
 
        .globl  __kuser_sigtramp
 __kuser_sigtramp:
--
Hi Chung-Lin
I thought this is our original intention for it.
Quoted 8 lines
First 4 bytes is the __kuser_version and each __kuser function will have 64 bytes size.
0x1000 __kuser_helper_version
0x1004 __kuser_cmpxchg
0x1044 __kuser_sigtramp
Any reason you can't use __kuser_sigtramp @ 0x1044?
Well, that's okay as well, as the main place which sets this is the signal frame construction in arch/nios2/kernel/signal.c. The user space is mostly oblivious to the exact location. You'll need to update it that way if you prefer 0x1044, as it's currently set at 0x1040.

Quoted 6 lines

Quoted 2 lines
I suggested 0x1040 because 64b frames aligned at 64b seemed more intuitive; __kuser_cmpxchg would be a special case.
I think I will change to 0x1044 in arch/nios2/kernel/signal.c. I can submit the fix.
Do you need to update toolchain for this change?

No, the toolchain is not affected by this change.

Thanks,
Chung-Lin

Ley Foon Tan

2015-01-22 09:12 UTC #5 lore raw

Quoted 74 lines · Chung-Lin Tang

Quoted 73 lines · Ley Foon Tan
Quoted 72 lines · Chung-Lin Tang
Quoted 57 lines · Ley Foon Tan
Quoted 42 lines · Chung-Lin Tang
The address of __kuser_sigtramp is wrong by one word, due to padding __kuser_cmpxchg to fully 64 bytes. The version word at the start of the page displaces __kuser_sigtramp to 0x1044, instead of the intended 0x1040.
Fixed by counting the 64-byte frame from the start of the page instead of __kuser_cmpxchg. This shortens the __kuser_cmpxchg frame to 60-bytes, but that's likely enough.
The zero-byte padding parts of the kuser_pad macro has been removed, due to the .if command refusing to behave properly when there are other .word directives in between. Probably a binutils gas bug.
Thanks,
Chung-Lin
Cc Ley Foon Tan <[email protected]>
Cc Tobias Klauser <[email protected]>
Signed-off-by Chung-Lin Tang <[email protected]>
arch/nios2/kernel/entry.S +1 -8
index 0bdfd13..3224839 100644
@@ -492,14 +492,7 @@ ENTRY(ret_from_kernel_thread)
 
  /* Filling pads with undefined instructions. */
 .macro kuser_pad sym size
-       .if     ((. - \sym) & 3)
-       .rept   (4 - (. - \sym) & 3)
-       .byte   0
-       .endr
-       .endif
-       .rept   ((\size - (. - \sym)) / 4)
-       .word   0xdeadbeef
-       .endr
+       .fill   ((\size - (. - \sym)) / 4), 4, 0xdeadbeef
 .endm
 
        .align  6
@@ -526,7 +519,10 @@ cmpxchg_stw:
 cmpxchg_ret:
        ret
arch/nios2/kernel/entry.S cmpxchg_stw:
Quoted 10 lines
arch/nios2/kernel/entry.S +4 -2
 
-       kuser_pad __kuser_cmpxchg, 64
+       /* The first 64-byte frame contains the version word, so note
+          that the first padding entry is based from the start of the kuser
+          page, instead of __kuser_cmpxchg.  */
+       kuser_pad __kuser_helper_start, 64
 
        .globl  __kuser_sigtramp
 __kuser_sigtramp:
--
Hi Chung-Lin
I thought this is our original intention for it.
Quoted 8 lines
First 4 bytes is the __kuser_version and each __kuser function will have 64 bytes size.
0x1000 __kuser_helper_version
0x1004 __kuser_cmpxchg
0x1044 __kuser_sigtramp
Any reason you can't use __kuser_sigtramp @ 0x1044?
Well, that's okay as well, as the main place which sets this is the signal frame construction in arch/nios2/kernel/signal.c. The user space is mostly oblivious to the exact location. You'll need to update it that way if you prefer 0x1044, as it's currently set at 0x1040.

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
I suggested 0x1040 because 64b frames aligned at 64b seemed more intuitive; __kuser_cmpxchg would be a special case.
I think I will change to 0x1044 in arch/nios2/kernel/signal.c. I can submit the fix.
Do you need to update toolchain for this change?
No, the toolchain is not affected by this change.

Okay, will fix this.