* [PATCH 0/3] arm64: Conversions to modern assembly annotations
@ 2020-01-06 19:58 Mark Brown
2020-01-06 19:58 ` [PATCH 1/3] arm64: asm: Add new-style position independent function annotations Mark Brown
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Mark Brown @ 2020-01-06 19:58 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon; +Cc: Mark Brown, linux-arm-kernel
As part of an effort to make the annotations in assembly code clearer and
more consistent new macros have been introduced. This series of patches
converts some more of the arm64 assembly code to these annotations,
patch 1 introduces modern equivalents of the arm64 specific ENDPIPROC()
which are then used by conversions of the lib and mm directories in the
other two patches.
Mark Brown (3):
arm64: asm: Add new-style position independent function annotations
arm64: lib: Use modern annotations for assembly functions
arm64: mm: Use modern annotations for assembly functions
arch/arm64/include/asm/linkage.h | 16 ++++++++++
arch/arm64/lib/clear_page.S | 4 +--
arch/arm64/lib/clear_user.S | 4 +--
arch/arm64/lib/copy_from_user.S | 4 +--
arch/arm64/lib/copy_in_user.S | 4 +--
arch/arm64/lib/copy_page.S | 4 +--
arch/arm64/lib/copy_to_user.S | 4 +--
arch/arm64/lib/crc32.S | 8 ++---
arch/arm64/lib/memchr.S | 4 +--
arch/arm64/lib/memcmp.S | 4 +--
arch/arm64/lib/memcpy.S | 8 ++---
arch/arm64/lib/memmove.S | 8 ++---
arch/arm64/lib/memset.S | 8 ++---
arch/arm64/lib/strchr.S | 4 +--
arch/arm64/lib/strcmp.S | 4 +--
arch/arm64/lib/strlen.S | 4 +--
arch/arm64/lib/strncmp.S | 4 +--
arch/arm64/lib/strnlen.S | 4 +--
arch/arm64/lib/strrchr.S | 4 +--
arch/arm64/lib/tishift.S | 12 ++++----
arch/arm64/mm/cache.S | 52 ++++++++++++++++----------------
arch/arm64/mm/proc.S | 24 +++++++--------
22 files changed, 104 insertions(+), 88 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 1/3] arm64: asm: Add new-style position independent function annotations
2020-01-06 19:58 [PATCH 0/3] arm64: Conversions to modern assembly annotations Mark Brown
@ 2020-01-06 19:58 ` Mark Brown
2020-01-07 14:44 ` Will Deacon
2020-01-06 19:58 ` [PATCH 2/3] arm64: lib: Use modern annotations for assembly functions Mark Brown
2020-01-06 19:58 ` [PATCH 3/3] arm64: mm: " Mark Brown
2 siblings, 1 reply; 16+ messages in thread
From: Mark Brown @ 2020-01-06 19:58 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon; +Cc: Mark Brown, linux-arm-kernel
As part of an effort to make the annotations in assembly code clearer and
more consistent new macros have been introduced, including replacements
for ENTRY() and ENDPROC().
On arm64 we have ENDPIPROC(), a custom version of ENDPROC() which is
used for code that will need to run in position independent environments
like EFI, it creates an alias for the function with the prefix __pi_ and
then emits the standard ENDPROC. Add new-style macros to replace this
which expand to the standard SYM_FUNC_*() and SYM_FUNC_ALIAS_*(),
resulting in the same object code. These are added in linkage.h for
consistency with where the generic assembler code has its macros.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/include/asm/linkage.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/include/asm/linkage.h b/arch/arm64/include/asm/linkage.h
index 1b266292f0be..23944ce14969 100644
--- a/arch/arm64/include/asm/linkage.h
+++ b/arch/arm64/include/asm/linkage.h
@@ -4,4 +4,20 @@
#define __ALIGN .align 2
#define __ALIGN_STR ".align 2"
+/*
+ * Annotate a function as position independent, i.e., safe to be called before
+ * the kernel virtual mapping is activated.
+ */
+#define SYM_FUNC_START_PI(x) \
+ SYM_FUNC_START_ALIAS(__pi_##x) ASM_NL \
+ SYM_FUNC_START(x)
+
+#define SYM_FUNC_START_PI_WEAK(x) \
+ SYM_FUNC_START_ALIAS(__pi_##x) ASM_NL \
+ SYM_FUNC_START_WEAK(x)
+
+#define SYM_FUNC_END_PI(x) \
+ SYM_FUNC_END(x) ASM_NL \
+ SYM_FUNC_END_ALIAS(__pi_##x)
+
#endif
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH 2/3] arm64: lib: Use modern annotations for assembly functions
2020-01-06 19:58 [PATCH 0/3] arm64: Conversions to modern assembly annotations Mark Brown
2020-01-06 19:58 ` [PATCH 1/3] arm64: asm: Add new-style position independent function annotations Mark Brown
@ 2020-01-06 19:58 ` Mark Brown
2020-01-07 14:44 ` Will Deacon
2020-01-06 19:58 ` [PATCH 3/3] arm64: mm: " Mark Brown
2 siblings, 1 reply; 16+ messages in thread
From: Mark Brown @ 2020-01-06 19:58 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon; +Cc: Mark Brown, linux-arm-kernel
In an effort to clarify and simplify the annotation of assembly functions
in the kernel new macros have been introduced. These replace ENTRY and
ENDPROC and also add a new annotation for static functions which previously
had no ENTRY equivalent. Update the annotations in the library code to the
new macros.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/lib/clear_page.S | 4 ++--
arch/arm64/lib/clear_user.S | 4 ++--
arch/arm64/lib/copy_from_user.S | 4 ++--
arch/arm64/lib/copy_in_user.S | 4 ++--
arch/arm64/lib/copy_page.S | 4 ++--
arch/arm64/lib/copy_to_user.S | 4 ++--
arch/arm64/lib/crc32.S | 8 ++++----
arch/arm64/lib/memchr.S | 4 ++--
arch/arm64/lib/memcmp.S | 4 ++--
arch/arm64/lib/memcpy.S | 8 ++++----
arch/arm64/lib/memmove.S | 8 ++++----
arch/arm64/lib/memset.S | 8 ++++----
arch/arm64/lib/strchr.S | 4 ++--
arch/arm64/lib/strcmp.S | 4 ++--
arch/arm64/lib/strlen.S | 4 ++--
arch/arm64/lib/strncmp.S | 4 ++--
arch/arm64/lib/strnlen.S | 4 ++--
arch/arm64/lib/strrchr.S | 4 ++--
arch/arm64/lib/tishift.S | 12 ++++++------
19 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/arch/arm64/lib/clear_page.S b/arch/arm64/lib/clear_page.S
index 78a9ef66288a..073acbf02a7c 100644
--- a/arch/arm64/lib/clear_page.S
+++ b/arch/arm64/lib/clear_page.S
@@ -14,7 +14,7 @@
* Parameters:
* x0 - dest
*/
-ENTRY(clear_page)
+SYM_FUNC_START(clear_page)
mrs x1, dczid_el0
and w1, w1, #0xf
mov x2, #4
@@ -25,5 +25,5 @@ ENTRY(clear_page)
tst x0, #(PAGE_SIZE - 1)
b.ne 1b
ret
-ENDPROC(clear_page)
+SYM_FUNC_END(clear_page)
EXPORT_SYMBOL(clear_page)
diff --git a/arch/arm64/lib/clear_user.S b/arch/arm64/lib/clear_user.S
index aeafc03e961a..48a3a26eff66 100644
--- a/arch/arm64/lib/clear_user.S
+++ b/arch/arm64/lib/clear_user.S
@@ -19,7 +19,7 @@
*
* Alignment fixed up by hardware.
*/
-ENTRY(__arch_clear_user)
+SYM_FUNC_START(__arch_clear_user)
mov x2, x1 // save the size for fixup return
subs x1, x1, #8
b.mi 2f
@@ -40,7 +40,7 @@ uao_user_alternative 9f, strh, sttrh, wzr, x0, 2
uao_user_alternative 9f, strb, sttrb, wzr, x0, 0
5: mov x0, #0
ret
-ENDPROC(__arch_clear_user)
+SYM_FUNC_END(__arch_clear_user)
EXPORT_SYMBOL(__arch_clear_user)
.section .fixup,"ax"
diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
index ebb3c06cbb5d..8e25e89ad01f 100644
--- a/arch/arm64/lib/copy_from_user.S
+++ b/arch/arm64/lib/copy_from_user.S
@@ -53,12 +53,12 @@
.endm
end .req x5
-ENTRY(__arch_copy_from_user)
+SYM_FUNC_START(__arch_copy_from_user)
add end, x0, x2
#include "copy_template.S"
mov x0, #0 // Nothing to copy
ret
-ENDPROC(__arch_copy_from_user)
+SYM_FUNC_END(__arch_copy_from_user)
EXPORT_SYMBOL(__arch_copy_from_user)
.section .fixup,"ax"
diff --git a/arch/arm64/lib/copy_in_user.S b/arch/arm64/lib/copy_in_user.S
index 3d8153a1ebce..667139013ed1 100644
--- a/arch/arm64/lib/copy_in_user.S
+++ b/arch/arm64/lib/copy_in_user.S
@@ -55,12 +55,12 @@
end .req x5
-ENTRY(__arch_copy_in_user)
+SYM_FUNC_START(__arch_copy_in_user)
add end, x0, x2
#include "copy_template.S"
mov x0, #0
ret
-ENDPROC(__arch_copy_in_user)
+SYM_FUNC_END(__arch_copy_in_user)
EXPORT_SYMBOL(__arch_copy_in_user)
.section .fixup,"ax"
diff --git a/arch/arm64/lib/copy_page.S b/arch/arm64/lib/copy_page.S
index bbb8562396af..e125a84eb400 100644
--- a/arch/arm64/lib/copy_page.S
+++ b/arch/arm64/lib/copy_page.S
@@ -17,7 +17,7 @@
* x0 - dest
* x1 - src
*/
-ENTRY(copy_page)
+SYM_FUNC_START(copy_page)
alternative_if ARM64_HAS_NO_HW_PREFETCH
// Prefetch three cache lines ahead.
prfm pldl1strm, [x1, #128]
@@ -75,5 +75,5 @@ alternative_else_nop_endif
stnp x16, x17, [x0, #112]
ret
-ENDPROC(copy_page)
+SYM_FUNC_END(copy_page)
EXPORT_SYMBOL(copy_page)
diff --git a/arch/arm64/lib/copy_to_user.S b/arch/arm64/lib/copy_to_user.S
index 357eae2c18eb..1a104d0089f3 100644
--- a/arch/arm64/lib/copy_to_user.S
+++ b/arch/arm64/lib/copy_to_user.S
@@ -52,12 +52,12 @@
.endm
end .req x5
-ENTRY(__arch_copy_to_user)
+SYM_FUNC_START(__arch_copy_to_user)
add end, x0, x2
#include "copy_template.S"
mov x0, #0
ret
-ENDPROC(__arch_copy_to_user)
+SYM_FUNC_END(__arch_copy_to_user)
EXPORT_SYMBOL(__arch_copy_to_user)
.section .fixup,"ax"
diff --git a/arch/arm64/lib/crc32.S b/arch/arm64/lib/crc32.S
index e6135f16649b..243e107e9896 100644
--- a/arch/arm64/lib/crc32.S
+++ b/arch/arm64/lib/crc32.S
@@ -85,17 +85,17 @@ CPU_BE( rev16 w3, w3 )
.endm
.align 5
-ENTRY(crc32_le)
+SYM_FUNC_START(crc32_le)
alternative_if_not ARM64_HAS_CRC32
b crc32_le_base
alternative_else_nop_endif
__crc32
-ENDPROC(crc32_le)
+SYM_FUNC_END(crc32_le)
.align 5
-ENTRY(__crc32c_le)
+SYM_FUNC_START(__crc32c_le)
alternative_if_not ARM64_HAS_CRC32
b __crc32c_le_base
alternative_else_nop_endif
__crc32 c
-ENDPROC(__crc32c_le)
+SYM_FUNC_END(__crc32c_le)
diff --git a/arch/arm64/lib/memchr.S b/arch/arm64/lib/memchr.S
index 48a3ab636e4f..99910c5d5db7 100644
--- a/arch/arm64/lib/memchr.S
+++ b/arch/arm64/lib/memchr.S
@@ -19,7 +19,7 @@
* Returns:
* x0 - address of first occurrence of 'c' or 0
*/
-WEAK(memchr)
+SYM_FUNC_START_PI_WEAK(memchr)
and w1, w1, #0xff
1: subs x2, x2, #1
b.mi 2f
@@ -30,5 +30,5 @@ WEAK(memchr)
ret
2: mov x0, #0
ret
-ENDPIPROC(memchr)
+SYM_FUNC_END_PI(memchr)
EXPORT_SYMBOL_NOKASAN(memchr)
diff --git a/arch/arm64/lib/memcmp.S b/arch/arm64/lib/memcmp.S
index b297bdaaf549..b889f312bdb3 100644
--- a/arch/arm64/lib/memcmp.S
+++ b/arch/arm64/lib/memcmp.S
@@ -46,7 +46,7 @@ pos .req x11
limit_wd .req x12
mask .req x13
-WEAK(memcmp)
+SYM_FUNC_START_PI_WEAK(memcmp)
cbz limit, .Lret0
eor tmp1, src1, src2
tst tmp1, #7
@@ -243,5 +243,5 @@ CPU_LE( rev data2, data2 )
.Lret0:
mov result, #0
ret
-ENDPIPROC(memcmp)
+SYM_FUNC_END_PI(memcmp)
EXPORT_SYMBOL_NOKASAN(memcmp)
diff --git a/arch/arm64/lib/memcpy.S b/arch/arm64/lib/memcpy.S
index d79f48994dbb..9f382adfa88a 100644
--- a/arch/arm64/lib/memcpy.S
+++ b/arch/arm64/lib/memcpy.S
@@ -57,11 +57,11 @@
.endm
.weak memcpy
-ENTRY(__memcpy)
-ENTRY(memcpy)
+SYM_FUNC_START_ALIAS(__memcpy)
+SYM_FUNC_START_PI(memcpy)
#include "copy_template.S"
ret
-ENDPIPROC(memcpy)
+SYM_FUNC_END_PI(memcpy)
EXPORT_SYMBOL(memcpy)
-ENDPROC(__memcpy)
+SYM_FUNC_END_ALIAS(__memcpy)
EXPORT_SYMBOL(__memcpy)
diff --git a/arch/arm64/lib/memmove.S b/arch/arm64/lib/memmove.S
index 784775136480..02cda2e33bde 100644
--- a/arch/arm64/lib/memmove.S
+++ b/arch/arm64/lib/memmove.S
@@ -46,8 +46,8 @@ D_l .req x13
D_h .req x14
.weak memmove
-ENTRY(__memmove)
-ENTRY(memmove)
+SYM_FUNC_START_ALIAS(__memmove)
+SYM_FUNC_START_PI(memmove)
cmp dstin, src
b.lo __memcpy
add tmp1, src, count
@@ -184,7 +184,7 @@ ENTRY(memmove)
tst count, #0x3f
b.ne .Ltail63
ret
-ENDPIPROC(memmove)
+SYM_FUNC_END_PI(memmove)
EXPORT_SYMBOL(memmove)
-ENDPROC(__memmove)
+SYM_FUNC_END_ALIAS(__memmove)
EXPORT_SYMBOL(__memmove)
diff --git a/arch/arm64/lib/memset.S b/arch/arm64/lib/memset.S
index 9fb97e6bc560..77c3c7ba0084 100644
--- a/arch/arm64/lib/memset.S
+++ b/arch/arm64/lib/memset.S
@@ -43,8 +43,8 @@ tmp3w .req w9
tmp3 .req x9
.weak memset
-ENTRY(__memset)
-ENTRY(memset)
+SYM_FUNC_START_ALIAS(__memset)
+SYM_FUNC_START_PI(memset)
mov dst, dstin /* Preserve return value. */
and A_lw, val, #255
orr A_lw, A_lw, A_lw, lsl #8
@@ -203,7 +203,7 @@ ENTRY(memset)
ands count, count, zva_bits_x
b.ne .Ltail_maybe_long
ret
-ENDPIPROC(memset)
+SYM_FUNC_END_PI(memset)
EXPORT_SYMBOL(memset)
-ENDPROC(__memset)
+SYM_FUNC_END_ALIAS(__memset)
EXPORT_SYMBOL(__memset)
diff --git a/arch/arm64/lib/strchr.S b/arch/arm64/lib/strchr.S
index ca3ec18171a4..1f47eae3b0d6 100644
--- a/arch/arm64/lib/strchr.S
+++ b/arch/arm64/lib/strchr.S
@@ -18,7 +18,7 @@
* Returns:
* x0 - address of first occurrence of 'c' or 0
*/
-WEAK(strchr)
+SYM_FUNC_START_WEAK(strchr)
and w1, w1, #0xff
1: ldrb w2, [x0], #1
cmp w2, w1
@@ -28,5 +28,5 @@ WEAK(strchr)
cmp w2, w1
csel x0, x0, xzr, eq
ret
-ENDPROC(strchr)
+SYM_FUNC_END(strchr)
EXPORT_SYMBOL_NOKASAN(strchr)
diff --git a/arch/arm64/lib/strcmp.S b/arch/arm64/lib/strcmp.S
index e9aefbe0b740..5f9bb9094d1f 100644
--- a/arch/arm64/lib/strcmp.S
+++ b/arch/arm64/lib/strcmp.S
@@ -48,7 +48,7 @@ tmp3 .req x9
zeroones .req x10
pos .req x11
-WEAK(strcmp)
+SYM_FUNC_START_PI_WEAK(strcmp)
eor tmp1, src1, src2
mov zeroones, #REP8_01
tst tmp1, #7
@@ -219,5 +219,5 @@ CPU_BE( orr syndrome, diff, has_nul )
lsr data1, data1, #56
sub result, data1, data2, lsr #56
ret
-ENDPIPROC(strcmp)
+SYM_FUNC_END_PI(strcmp)
EXPORT_SYMBOL_NOKASAN(strcmp)
diff --git a/arch/arm64/lib/strlen.S b/arch/arm64/lib/strlen.S
index 87b0cb066915..f71b4b94d4b2 100644
--- a/arch/arm64/lib/strlen.S
+++ b/arch/arm64/lib/strlen.S
@@ -44,7 +44,7 @@ pos .req x12
#define REP8_7f 0x7f7f7f7f7f7f7f7f
#define REP8_80 0x8080808080808080
-WEAK(strlen)
+SYM_FUNC_START_PI_WEAK(strlen)
mov zeroones, #REP8_01
bic src, srcin, #15
ands tmp1, srcin, #15
@@ -111,5 +111,5 @@ CPU_LE( lsr tmp2, tmp2, tmp1 ) /* Shift (tmp1 & 63). */
csinv data1, data1, xzr, le
csel data2, data2, data2a, le
b .Lrealigned
-ENDPIPROC(strlen)
+SYM_FUNC_END_PI(strlen)
EXPORT_SYMBOL_NOKASAN(strlen)
diff --git a/arch/arm64/lib/strncmp.S b/arch/arm64/lib/strncmp.S
index f571581888fa..6df88cd9c6f2 100644
--- a/arch/arm64/lib/strncmp.S
+++ b/arch/arm64/lib/strncmp.S
@@ -52,7 +52,7 @@ limit_wd .req x13
mask .req x14
endloop .req x15
-WEAK(strncmp)
+SYM_FUNC_START_PI_WEAK(strncmp)
cbz limit, .Lret0
eor tmp1, src1, src2
mov zeroones, #REP8_01
@@ -295,5 +295,5 @@ CPU_BE( orr syndrome, diff, has_nul )
.Lret0:
mov result, #0
ret
-ENDPIPROC(strncmp)
+SYM_FUNC_END_PI(strncmp)
EXPORT_SYMBOL_NOKASAN(strncmp)
diff --git a/arch/arm64/lib/strnlen.S b/arch/arm64/lib/strnlen.S
index c0bac9493c68..2fadeeff6ff4 100644
--- a/arch/arm64/lib/strnlen.S
+++ b/arch/arm64/lib/strnlen.S
@@ -47,7 +47,7 @@ limit_wd .req x14
#define REP8_7f 0x7f7f7f7f7f7f7f7f
#define REP8_80 0x8080808080808080
-WEAK(strnlen)
+SYM_FUNC_START_PI_WEAK(strnlen)
cbz limit, .Lhit_limit
mov zeroones, #REP8_01
bic src, srcin, #15
@@ -156,5 +156,5 @@ CPU_LE( lsr tmp2, tmp2, tmp4 ) /* Shift (tmp1 & 63). */
.Lhit_limit:
mov len, limit
ret
-ENDPIPROC(strnlen)
+SYM_FUNC_END_PI(strnlen)
EXPORT_SYMBOL_NOKASAN(strnlen)
diff --git a/arch/arm64/lib/strrchr.S b/arch/arm64/lib/strrchr.S
index 794ac49ea433..9a9936e0c6f3 100644
--- a/arch/arm64/lib/strrchr.S
+++ b/arch/arm64/lib/strrchr.S
@@ -18,7 +18,7 @@
* Returns:
* x0 - address of last occurrence of 'c' or 0
*/
-WEAK(strrchr)
+SYM_FUNC_START_PI_WEAK(strrchr)
mov x3, #0
and w1, w1, #0xff
1: ldrb w2, [x0], #1
@@ -29,5 +29,5 @@ WEAK(strrchr)
b 1b
2: mov x0, x3
ret
-ENDPIPROC(strrchr)
+SYM_FUNC_END_PI(strrchr)
EXPORT_SYMBOL_NOKASAN(strrchr)
diff --git a/arch/arm64/lib/tishift.S b/arch/arm64/lib/tishift.S
index 047622536535..a88613834fb0 100644
--- a/arch/arm64/lib/tishift.S
+++ b/arch/arm64/lib/tishift.S
@@ -7,7 +7,7 @@
#include <asm/assembler.h>
-ENTRY(__ashlti3)
+SYM_FUNC_START(__ashlti3)
cbz x2, 1f
mov x3, #64
sub x3, x3, x2
@@ -26,10 +26,10 @@ ENTRY(__ashlti3)
lsl x1, x0, x1
mov x0, x2
ret
-ENDPROC(__ashlti3)
+SYM_FUNC_END(__ashlti3)
EXPORT_SYMBOL(__ashlti3)
-ENTRY(__ashrti3)
+SYM_FUNC_START(__ashrti3)
cbz x2, 1f
mov x3, #64
sub x3, x3, x2
@@ -48,10 +48,10 @@ ENTRY(__ashrti3)
asr x0, x1, x0
mov x1, x2
ret
-ENDPROC(__ashrti3)
+SYM_FUNC_END(__ashrti3)
EXPORT_SYMBOL(__ashrti3)
-ENTRY(__lshrti3)
+SYM_FUNC_START(__lshrti3)
cbz x2, 1f
mov x3, #64
sub x3, x3, x2
@@ -70,5 +70,5 @@ ENTRY(__lshrti3)
lsr x0, x1, x0
mov x1, x2
ret
-ENDPROC(__lshrti3)
+SYM_FUNC_END(__lshrti3)
EXPORT_SYMBOL(__lshrti3)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH 3/3] arm64: mm: Use modern annotations for assembly functions
2020-01-06 19:58 [PATCH 0/3] arm64: Conversions to modern assembly annotations Mark Brown
2020-01-06 19:58 ` [PATCH 1/3] arm64: asm: Add new-style position independent function annotations Mark Brown
2020-01-06 19:58 ` [PATCH 2/3] arm64: lib: Use modern annotations for assembly functions Mark Brown
@ 2020-01-06 19:58 ` Mark Brown
2020-01-07 14:43 ` Will Deacon
2 siblings, 1 reply; 16+ messages in thread
From: Mark Brown @ 2020-01-06 19:58 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon; +Cc: Mark Brown, linux-arm-kernel
In an effort to clarify and simplify the annotation of assembly functions
in the kernel new macros have been introduced. These replace ENTRY and
ENDPROC and also add a new annotation for static functions which previously
had no ENTRY equivalent. Update the annotations in the mm code to the
new macros. Even the functions called from non-standard environments
like idmap have no special requirements on their environments so can be
treated like regular functions.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/mm/cache.S | 52 +++++++++++++++++++++----------------------
arch/arm64/mm/proc.S | 24 ++++++++++----------
2 files changed, 38 insertions(+), 38 deletions(-)
diff --git a/arch/arm64/mm/cache.S b/arch/arm64/mm/cache.S
index db767b072601..2d881f34dd9d 100644
--- a/arch/arm64/mm/cache.S
+++ b/arch/arm64/mm/cache.S
@@ -24,7 +24,7 @@
* - start - virtual start address of region
* - end - virtual end address of region
*/
-ENTRY(__flush_icache_range)
+SYM_FUNC_START(__flush_icache_range)
/* FALLTHROUGH */
/*
@@ -37,7 +37,7 @@ ENTRY(__flush_icache_range)
* - start - virtual start address of region
* - end - virtual end address of region
*/
-ENTRY(__flush_cache_user_range)
+SYM_FUNC_START(__flush_cache_user_range)
uaccess_ttbr0_enable x2, x3, x4
alternative_if ARM64_HAS_CACHE_IDC
dsb ishst
@@ -66,8 +66,8 @@ alternative_else_nop_endif
9:
mov x0, #-EFAULT
b 1b
-ENDPROC(__flush_icache_range)
-ENDPROC(__flush_cache_user_range)
+SYM_FUNC_END(__flush_icache_range)
+SYM_FUNC_END(__flush_cache_user_range)
/*
* invalidate_icache_range(start,end)
@@ -77,7 +77,7 @@ ENDPROC(__flush_cache_user_range)
* - start - virtual start address of region
* - end - virtual end address of region
*/
-ENTRY(invalidate_icache_range)
+SYM_FUNC_START(invalidate_icache_range)
alternative_if ARM64_HAS_CACHE_DIC
mov x0, xzr
isb
@@ -94,7 +94,7 @@ alternative_else_nop_endif
2:
mov x0, #-EFAULT
b 1b
-ENDPROC(invalidate_icache_range)
+SYM_FUNC_END(invalidate_icache_range)
/*
* __flush_dcache_area(kaddr, size)
@@ -105,10 +105,10 @@ ENDPROC(invalidate_icache_range)
* - kaddr - kernel address
* - size - size in question
*/
-ENTRY(__flush_dcache_area)
+SYM_FUNC_START_PI(__flush_dcache_area)
dcache_by_line_op civac, sy, x0, x1, x2, x3
ret
-ENDPIPROC(__flush_dcache_area)
+SYM_FUNC_END_PI(__flush_dcache_area)
/*
* __clean_dcache_area_pou(kaddr, size)
@@ -119,14 +119,14 @@ ENDPIPROC(__flush_dcache_area)
* - kaddr - kernel address
* - size - size in question
*/
-ENTRY(__clean_dcache_area_pou)
+SYM_FUNC_START(__clean_dcache_area_pou)
alternative_if ARM64_HAS_CACHE_IDC
dsb ishst
ret
alternative_else_nop_endif
dcache_by_line_op cvau, ish, x0, x1, x2, x3
ret
-ENDPROC(__clean_dcache_area_pou)
+SYM_FUNC_END(__clean_dcache_area_pou)
/*
* __inval_dcache_area(kaddr, size)
@@ -138,7 +138,8 @@ ENDPROC(__clean_dcache_area_pou)
* - kaddr - kernel address
* - size - size in question
*/
-ENTRY(__inval_dcache_area)
+SYM_FUNC_START_LOCAL(__dma_inv_area)
+SYM_FUNC_START_PI(__inval_dcache_area)
/* FALLTHROUGH */
/*
@@ -146,7 +147,6 @@ ENTRY(__inval_dcache_area)
* - start - virtual start address of region
* - size - size in question
*/
-__dma_inv_area:
add x1, x1, x0
dcache_line_size x2, x3
sub x3, x2, #1
@@ -165,8 +165,8 @@ __dma_inv_area:
b.lo 2b
dsb sy
ret
-ENDPIPROC(__inval_dcache_area)
-ENDPROC(__dma_inv_area)
+SYM_FUNC_END_PI(__inval_dcache_area)
+SYM_FUNC_END(__dma_inv_area)
/*
* __clean_dcache_area_poc(kaddr, size)
@@ -177,7 +177,8 @@ ENDPROC(__dma_inv_area)
* - kaddr - kernel address
* - size - size in question
*/
-ENTRY(__clean_dcache_area_poc)
+SYM_FUNC_START_LOCAL(__dma_clean_area)
+SYM_FUNC_START_PI(__clean_dcache_area_poc)
/* FALLTHROUGH */
/*
@@ -185,11 +186,10 @@ ENTRY(__clean_dcache_area_poc)
* - start - virtual start address of region
* - size - size in question
*/
-__dma_clean_area:
dcache_by_line_op cvac, sy, x0, x1, x2, x3
ret
-ENDPIPROC(__clean_dcache_area_poc)
-ENDPROC(__dma_clean_area)
+SYM_FUNC_END_PI(__clean_dcache_area_poc)
+SYM_FUNC_END(__dma_clean_area)
/*
* __clean_dcache_area_pop(kaddr, size)
@@ -200,13 +200,13 @@ ENDPROC(__dma_clean_area)
* - kaddr - kernel address
* - size - size in question
*/
-ENTRY(__clean_dcache_area_pop)
+SYM_FUNC_START_PI(__clean_dcache_area_pop)
alternative_if_not ARM64_HAS_DCPOP
b __clean_dcache_area_poc
alternative_else_nop_endif
dcache_by_line_op cvap, sy, x0, x1, x2, x3
ret
-ENDPIPROC(__clean_dcache_area_pop)
+SYM_FUNC_END_PI(__clean_dcache_area_pop)
/*
* __dma_flush_area(start, size)
@@ -216,10 +216,10 @@ ENDPIPROC(__clean_dcache_area_pop)
* - start - virtual start address of region
* - size - size in question
*/
-ENTRY(__dma_flush_area)
+SYM_FUNC_START_PI(__dma_flush_area)
dcache_by_line_op civac, sy, x0, x1, x2, x3
ret
-ENDPIPROC(__dma_flush_area)
+SYM_FUNC_END_PI(__dma_flush_area)
/*
* __dma_map_area(start, size, dir)
@@ -227,11 +227,11 @@ ENDPIPROC(__dma_flush_area)
* - size - size of region
* - dir - DMA direction
*/
-ENTRY(__dma_map_area)
+SYM_FUNC_START_PI(__dma_map_area)
cmp w2, #DMA_FROM_DEVICE
b.eq __dma_inv_area
b __dma_clean_area
-ENDPIPROC(__dma_map_area)
+SYM_FUNC_END_PI(__dma_map_area)
/*
* __dma_unmap_area(start, size, dir)
@@ -239,8 +239,8 @@ ENDPIPROC(__dma_map_area)
* - size - size of region
* - dir - DMA direction
*/
-ENTRY(__dma_unmap_area)
+SYM_FUNC_START_PI(__dma_unmap_area)
cmp w2, #DMA_TO_DEVICE
b.ne __dma_inv_area
ret
-ENDPIPROC(__dma_unmap_area)
+SYM_FUNC_END_PI(__dma_unmap_area)
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index a1e0592d1fbc..9a8b1b14ce02 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -50,7 +50,7 @@
*
* x0: virtual address of context pointer
*/
-ENTRY(cpu_do_suspend)
+SYM_FUNC_START(cpu_do_suspend)
mrs x2, tpidr_el0
mrs x3, tpidrro_el0
mrs x4, contextidr_el1
@@ -74,7 +74,7 @@ alternative_endif
stp x10, x11, [x0, #64]
stp x12, x13, [x0, #80]
ret
-ENDPROC(cpu_do_suspend)
+SYM_FUNC_END(cpu_do_suspend)
/**
* cpu_do_resume - restore CPU register context
@@ -82,7 +82,7 @@ ENDPROC(cpu_do_suspend)
* x0: Address of context pointer
*/
.pushsection ".idmap.text", "awx"
-ENTRY(cpu_do_resume)
+SYM_FUNC_START(cpu_do_resume)
ldp x2, x3, [x0]
ldp x4, x5, [x0, #16]
ldp x6, x8, [x0, #32]
@@ -131,7 +131,7 @@ alternative_else_nop_endif
isb
ret
-ENDPROC(cpu_do_resume)
+SYM_FUNC_END(cpu_do_resume)
.popsection
#endif
@@ -142,7 +142,7 @@ ENDPROC(cpu_do_resume)
*
* - pgd_phys - physical address of new TTB
*/
-ENTRY(cpu_do_switch_mm)
+SYM_FUNC_START(cpu_do_switch_mm)
mrs x2, ttbr1_el1
mmid x1, x1 // get mm->context.id
phys_to_ttbr x3, x0
@@ -161,7 +161,7 @@ alternative_else_nop_endif
msr ttbr0_el1, x3 // now update TTBR0
isb
b post_ttbr_update_workaround // Back to C code...
-ENDPROC(cpu_do_switch_mm)
+SYM_FUNC_END(cpu_do_switch_mm)
.pushsection ".idmap.text", "awx"
@@ -182,7 +182,7 @@ ENDPROC(cpu_do_switch_mm)
* This is the low-level counterpart to cpu_replace_ttbr1, and should not be
* called by anything else. It can only be executed from a TTBR0 mapping.
*/
-ENTRY(idmap_cpu_replace_ttbr1)
+SYM_FUNC_START(idmap_cpu_replace_ttbr1)
save_and_disable_daif flags=x2
__idmap_cpu_set_reserved_ttbr1 x1, x3
@@ -194,7 +194,7 @@ ENTRY(idmap_cpu_replace_ttbr1)
restore_daif x2
ret
-ENDPROC(idmap_cpu_replace_ttbr1)
+SYM_FUNC_END(idmap_cpu_replace_ttbr1)
.popsection
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
@@ -222,7 +222,7 @@ ENDPROC(idmap_cpu_replace_ttbr1)
*/
__idmap_kpti_flag:
.long 1
-ENTRY(idmap_kpti_install_ng_mappings)
+SYM_FUNC_START(idmap_kpti_install_ng_mappings)
cpu .req w0
num_cpus .req w1
swapper_pa .req x2
@@ -393,7 +393,7 @@ __idmap_kpti_secondary:
.unreq cur_ptep
.unreq end_ptep
.unreq pte
-ENDPROC(idmap_kpti_install_ng_mappings)
+SYM_FUNC_END(idmap_kpti_install_ng_mappings)
.popsection
#endif
@@ -404,7 +404,7 @@ ENDPROC(idmap_kpti_install_ng_mappings)
* value of the SCTLR_EL1 register.
*/
.pushsection ".idmap.text", "awx"
-ENTRY(__cpu_setup)
+SYM_FUNC_START(__cpu_setup)
tlbi vmalle1 // Invalidate local TLB
dsb nsh
@@ -475,4 +475,4 @@ ENTRY(__cpu_setup)
#endif /* CONFIG_ARM64_HW_AFDBM */
msr tcr_el1, x10
ret // return to head.S
-ENDPROC(__cpu_setup)
+SYM_FUNC_END(__cpu_setup)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] arm64: mm: Use modern annotations for assembly functions
2020-01-06 19:58 ` [PATCH 3/3] arm64: mm: " Mark Brown
@ 2020-01-07 14:43 ` Will Deacon
2020-01-07 16:42 ` Mark Brown
0 siblings, 1 reply; 16+ messages in thread
From: Will Deacon @ 2020-01-07 14:43 UTC (permalink / raw)
To: Mark Brown; +Cc: Catalin Marinas, linux-arm-kernel
On Mon, Jan 06, 2020 at 07:58:18PM +0000, Mark Brown wrote:
> In an effort to clarify and simplify the annotation of assembly functions
> in the kernel new macros have been introduced. These replace ENTRY and
> ENDPROC and also add a new annotation for static functions which previously
> had no ENTRY equivalent. Update the annotations in the mm code to the
> new macros. Even the functions called from non-standard environments
> like idmap have no special requirements on their environments so can be
> treated like regular functions.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> arch/arm64/mm/cache.S | 52 +++++++++++++++++++++----------------------
> arch/arm64/mm/proc.S | 24 ++++++++++----------
> 2 files changed, 38 insertions(+), 38 deletions(-)
Can we remove ENDPIPROC after this patch?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] arm64: asm: Add new-style position independent function annotations
2020-01-06 19:58 ` [PATCH 1/3] arm64: asm: Add new-style position independent function annotations Mark Brown
@ 2020-01-07 14:44 ` Will Deacon
2020-01-07 16:45 ` Mark Brown
0 siblings, 1 reply; 16+ messages in thread
From: Will Deacon @ 2020-01-07 14:44 UTC (permalink / raw)
To: Mark Brown; +Cc: Catalin Marinas, linux-arm-kernel
On Mon, Jan 06, 2020 at 07:58:16PM +0000, Mark Brown wrote:
> As part of an effort to make the annotations in assembly code clearer and
> more consistent new macros have been introduced, including replacements
> for ENTRY() and ENDPROC().
>
> On arm64 we have ENDPIPROC(), a custom version of ENDPROC() which is
> used for code that will need to run in position independent environments
> like EFI, it creates an alias for the function with the prefix __pi_ and
> then emits the standard ENDPROC. Add new-style macros to replace this
> which expand to the standard SYM_FUNC_*() and SYM_FUNC_ALIAS_*(),
> resulting in the same object code. These are added in linkage.h for
> consistency with where the generic assembler code has its macros.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> arch/arm64/include/asm/linkage.h | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/include/asm/linkage.h b/arch/arm64/include/asm/linkage.h
> index 1b266292f0be..23944ce14969 100644
> --- a/arch/arm64/include/asm/linkage.h
> +++ b/arch/arm64/include/asm/linkage.h
> @@ -4,4 +4,20 @@
> #define __ALIGN .align 2
> #define __ALIGN_STR ".align 2"
>
> +/*
> + * Annotate a function as position independent, i.e., safe to be called before
> + * the kernel virtual mapping is activated.
> + */
> +#define SYM_FUNC_START_PI(x) \
> + SYM_FUNC_START_ALIAS(__pi_##x) ASM_NL \
> + SYM_FUNC_START(x)
> +
> +#define SYM_FUNC_START_PI_WEAK(x) \
> + SYM_FUNC_START_ALIAS(__pi_##x) ASM_NL \
> + SYM_FUNC_START_WEAK(x)
Naming's hard, but I think this is particularly bad because it reads to me
like it's declaring a weak, position-independent symbol, whereas the weak
symbol is actually the version without the "__pi_" prefix. Maybe
SYM_FUNC_START_WEAK_PI() is a tiny bit better? Hrm.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] arm64: lib: Use modern annotations for assembly functions
2020-01-06 19:58 ` [PATCH 2/3] arm64: lib: Use modern annotations for assembly functions Mark Brown
@ 2020-01-07 14:44 ` Will Deacon
2020-01-07 17:47 ` Mark Brown
0 siblings, 1 reply; 16+ messages in thread
From: Will Deacon @ 2020-01-07 14:44 UTC (permalink / raw)
To: Mark Brown; +Cc: Catalin Marinas, linux-arm-kernel, jslaby
Hi Mark,
[+Jiri -- couple of questions below]
On Mon, Jan 06, 2020 at 07:58:17PM +0000, Mark Brown wrote:
> In an effort to clarify and simplify the annotation of assembly functions
> in the kernel new macros have been introduced. These replace ENTRY and
> ENDPROC and also add a new annotation for static functions which previously
> had no ENTRY equivalent. Update the annotations in the library code to the
> new macros.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> arch/arm64/lib/clear_page.S | 4 ++--
> arch/arm64/lib/clear_user.S | 4 ++--
> arch/arm64/lib/copy_from_user.S | 4 ++--
> arch/arm64/lib/copy_in_user.S | 4 ++--
> arch/arm64/lib/copy_page.S | 4 ++--
> arch/arm64/lib/copy_to_user.S | 4 ++--
> arch/arm64/lib/crc32.S | 8 ++++----
> arch/arm64/lib/memchr.S | 4 ++--
> arch/arm64/lib/memcmp.S | 4 ++--
> arch/arm64/lib/memcpy.S | 8 ++++----
> arch/arm64/lib/memmove.S | 8 ++++----
> arch/arm64/lib/memset.S | 8 ++++----
> arch/arm64/lib/strchr.S | 4 ++--
> arch/arm64/lib/strcmp.S | 4 ++--
> arch/arm64/lib/strlen.S | 4 ++--
> arch/arm64/lib/strncmp.S | 4 ++--
> arch/arm64/lib/strnlen.S | 4 ++--
> arch/arm64/lib/strrchr.S | 4 ++--
> arch/arm64/lib/tishift.S | 12 ++++++------
> 19 files changed, 50 insertions(+), 50 deletions(-)
>
> diff --git a/arch/arm64/lib/clear_page.S b/arch/arm64/lib/clear_page.S
> index 78a9ef66288a..073acbf02a7c 100644
> --- a/arch/arm64/lib/clear_page.S
> +++ b/arch/arm64/lib/clear_page.S
> @@ -14,7 +14,7 @@
> * Parameters:
> * x0 - dest
> */
> -ENTRY(clear_page)
> +SYM_FUNC_START(clear_page)
> mrs x1, dczid_el0
> and w1, w1, #0xf
> mov x2, #4
Since this doesn't change behaviour, I think the patch is fine, however
on reading Documentation/asm-annotations.rst it's not completely clear to
me when SYM_FUNC_START() should be used. In this case, for example, we are
*not* pushing a stackframe and that would appear to be at odds with the
documentation.
Jiri -- is it ok to omit the stack frame for leaf functions annotated with
SYM_FUNC_START? I'm guessing it should be, since the link register isn't
going to be clobbered. Could we update the documentation to reflect that?
> diff --git a/arch/arm64/lib/crc32.S b/arch/arm64/lib/crc32.S
> index e6135f16649b..243e107e9896 100644
> --- a/arch/arm64/lib/crc32.S
> +++ b/arch/arm64/lib/crc32.S
> @@ -85,17 +85,17 @@ CPU_BE( rev16 w3, w3 )
> .endm
>
> .align 5
> -ENTRY(crc32_le)
> +SYM_FUNC_START(crc32_le)
> alternative_if_not ARM64_HAS_CRC32
> b crc32_le_base
Similar thing here -- I'm assuming we are ok to tail-call crc32_le_base()
from a function marked with SYM_FUNC_START like this?
> alternative_else_nop_endif
> __crc32
> -ENDPROC(crc32_le)
> +SYM_FUNC_END(crc32_le)
>
> .align 5
> -ENTRY(__crc32c_le)
> +SYM_FUNC_START(__crc32c_le)
> alternative_if_not ARM64_HAS_CRC32
> b __crc32c_le_base
> alternative_else_nop_endif
> __crc32 c
> -ENDPROC(__crc32c_le)
> +SYM_FUNC_END(__crc32c_le)
> diff --git a/arch/arm64/lib/memchr.S b/arch/arm64/lib/memchr.S
> index 48a3ab636e4f..99910c5d5db7 100644
> --- a/arch/arm64/lib/memchr.S
> +++ b/arch/arm64/lib/memchr.S
> @@ -19,7 +19,7 @@
> * Returns:
> * x0 - address of first occurrence of 'c' or 0
> */
> -WEAK(memchr)
> +SYM_FUNC_START_PI_WEAK(memchr)
> and w1, w1, #0xff
> 1: subs x2, x2, #1
> b.mi 2f
> @@ -30,5 +30,5 @@ WEAK(memchr)
> ret
> 2: mov x0, #0
> ret
> -ENDPIPROC(memchr)
> +SYM_FUNC_END_PI(memchr)
> EXPORT_SYMBOL_NOKASAN(memchr)
> diff --git a/arch/arm64/lib/memcmp.S b/arch/arm64/lib/memcmp.S
> index b297bdaaf549..b889f312bdb3 100644
> --- a/arch/arm64/lib/memcmp.S
> +++ b/arch/arm64/lib/memcmp.S
> @@ -46,7 +46,7 @@ pos .req x11
> limit_wd .req x12
> mask .req x13
>
> -WEAK(memcmp)
> +SYM_FUNC_START_PI_WEAK(memcmp)
> cbz limit, .Lret0
> eor tmp1, src1, src2
> tst tmp1, #7
> @@ -243,5 +243,5 @@ CPU_LE( rev data2, data2 )
> .Lret0:
> mov result, #0
> ret
> -ENDPIPROC(memcmp)
> +SYM_FUNC_END_PI(memcmp)
> EXPORT_SYMBOL_NOKASAN(memcmp)
> diff --git a/arch/arm64/lib/memcpy.S b/arch/arm64/lib/memcpy.S
> index d79f48994dbb..9f382adfa88a 100644
> --- a/arch/arm64/lib/memcpy.S
> +++ b/arch/arm64/lib/memcpy.S
> @@ -57,11 +57,11 @@
> .endm
>
> .weak memcpy
Hmm, any idea why we use .weak explicitly here? Maybe better off using
the proper macros now? (same applies to many of the other lib/ functions
you're touching)
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] arm64: mm: Use modern annotations for assembly functions
2020-01-07 14:43 ` Will Deacon
@ 2020-01-07 16:42 ` Mark Brown
2020-01-08 12:17 ` Will Deacon
0 siblings, 1 reply; 16+ messages in thread
From: Mark Brown @ 2020-01-07 16:42 UTC (permalink / raw)
To: Will Deacon; +Cc: Catalin Marinas, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 670 bytes --]
On Tue, Jan 07, 2020 at 02:43:58PM +0000, Will Deacon wrote:
> On Mon, Jan 06, 2020 at 07:58:18PM +0000, Mark Brown wrote:
> > In an effort to clarify and simplify the annotation of assembly functions
> > in the kernel new macros have been introduced. These replace ENTRY and
> > ENDPROC and also add a new annotation for static functions which previously
> Can we remove ENDPIPROC after this patch?
We can eventually, there's more stuff coming (very soon) for kernel/ and
kvm/ - once those are in I've got a patch sitting ready to remove
ENDPIPROC. That's basically the only patch for any of this stuff with
any interdependencies so I'm sending stuff as it's ready.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] arm64: asm: Add new-style position independent function annotations
2020-01-07 14:44 ` Will Deacon
@ 2020-01-07 16:45 ` Mark Brown
0 siblings, 0 replies; 16+ messages in thread
From: Mark Brown @ 2020-01-07 16:45 UTC (permalink / raw)
To: Will Deacon; +Cc: Catalin Marinas, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 663 bytes --]
On Tue, Jan 07, 2020 at 02:44:08PM +0000, Will Deacon wrote:
> On Mon, Jan 06, 2020 at 07:58:16PM +0000, Mark Brown wrote:
> > +#define SYM_FUNC_START_PI_WEAK(x) \
> > + SYM_FUNC_START_ALIAS(__pi_##x) ASM_NL \
> > + SYM_FUNC_START_WEAK(x)
> Naming's hard, but I think this is particularly bad because it reads to me
> like it's declaring a weak, position-independent symbol, whereas the weak
> symbol is actually the version without the "__pi_" prefix. Maybe
> SYM_FUNC_START_WEAK_PI() is a tiny bit better? Hrm.
I really don't have strong feelings about the name, if you're happy with
_WEAK_PI I'm more than happy to go with that. Like you say it's messy.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] arm64: lib: Use modern annotations for assembly functions
2020-01-07 14:44 ` Will Deacon
@ 2020-01-07 17:47 ` Mark Brown
2020-01-08 12:29 ` Will Deacon
0 siblings, 1 reply; 16+ messages in thread
From: Mark Brown @ 2020-01-07 17:47 UTC (permalink / raw)
To: Will Deacon; +Cc: Catalin Marinas, linux-arm-kernel, jslaby
[-- Attachment #1.1: Type: text/plain, Size: 2104 bytes --]
On Tue, Jan 07, 2020 at 02:44:46PM +0000, Will Deacon wrote:
> On Mon, Jan 06, 2020 at 07:58:17PM +0000, Mark Brown wrote:
> > -ENTRY(clear_page)
> > +SYM_FUNC_START(clear_page)
> > mrs x1, dczid_el0
> > and w1, w1, #0xf
> > mov x2, #4
> Since this doesn't change behaviour, I think the patch is fine, however
> on reading Documentation/asm-annotations.rst it's not completely clear to
> me when SYM_FUNC_START() should be used. In this case, for example, we are
> *not* pushing a stackframe and that would appear to be at odds with the
> documentation.
> Jiri -- is it ok to omit the stack frame for leaf functions annotated with
> SYM_FUNC_START? I'm guessing it should be, since the link register isn't
> going to be clobbered. Could we update the documentation to reflect that?
Yeah, the documentation isn't great on that. I was going on the basis
of both trying to minimize changes to the generated output as part of
the bulk change and looking at it from the point of view of the caller -
if as in this case the caller thinks it's a regular C function it seems
sensible to annotate it as such.
> > --- a/arch/arm64/lib/memcpy.S
> > +++ b/arch/arm64/lib/memcpy.S
> > @@ -57,11 +57,11 @@
> > .endm
> >
> > .weak memcpy
> Hmm, any idea why we use .weak explicitly here? Maybe better off using
> the proper macros now? (same applies to many of the other lib/ functions
> you're touching)
Nope, there's a whole bunch of stuff where what we're currently doing is
a bit interesting and I'm a bit worried that we might be relying on some
of it. My theory here was to do the bulk of the changes as a 1:1
replacement so the generated output is as close as possible for any big
changes and then do anything more detailed that isn't actually *needed*
on top of that. It's looking like there'll also be some stuff that
definitely changes the output going in as well, I was going to do those
as individual patches so that it's easier to find any breakages that get
introduced and so the big, repetitive changes don't have other stuff
mixed in.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] arm64: mm: Use modern annotations for assembly functions
2020-01-07 16:42 ` Mark Brown
@ 2020-01-08 12:17 ` Will Deacon
2020-01-08 13:50 ` Mark Brown
0 siblings, 1 reply; 16+ messages in thread
From: Will Deacon @ 2020-01-08 12:17 UTC (permalink / raw)
To: Mark Brown; +Cc: Catalin Marinas, linux-arm-kernel
On Tue, Jan 07, 2020 at 04:42:34PM +0000, Mark Brown wrote:
> On Tue, Jan 07, 2020 at 02:43:58PM +0000, Will Deacon wrote:
> > On Mon, Jan 06, 2020 at 07:58:18PM +0000, Mark Brown wrote:
> > > In an effort to clarify and simplify the annotation of assembly functions
> > > in the kernel new macros have been introduced. These replace ENTRY and
> > > ENDPROC and also add a new annotation for static functions which previously
>
> > Can we remove ENDPIPROC after this patch?
>
> We can eventually, there's more stuff coming (very soon) for kernel/ and
> kvm/ - once those are in I've got a patch sitting ready to remove
> ENDPIPROC. That's basically the only patch for any of this stuff with
> any interdependencies so I'm sending stuff as it's ready.
Hmm, but with this series applied I don't see any remaining users of
ENDPIPROC. Or are you saying that there are new users in the pipeline?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] arm64: lib: Use modern annotations for assembly functions
2020-01-07 17:47 ` Mark Brown
@ 2020-01-08 12:29 ` Will Deacon
2020-01-10 16:56 ` Jiri Slaby
0 siblings, 1 reply; 16+ messages in thread
From: Will Deacon @ 2020-01-08 12:29 UTC (permalink / raw)
To: Mark Brown; +Cc: Catalin Marinas, linux-arm-kernel, jslaby
On Tue, Jan 07, 2020 at 05:47:41PM +0000, Mark Brown wrote:
> On Tue, Jan 07, 2020 at 02:44:46PM +0000, Will Deacon wrote:
> > On Mon, Jan 06, 2020 at 07:58:17PM +0000, Mark Brown wrote:
>
> > > -ENTRY(clear_page)
> > > +SYM_FUNC_START(clear_page)
> > > mrs x1, dczid_el0
> > > and w1, w1, #0xf
> > > mov x2, #4
>
> > Since this doesn't change behaviour, I think the patch is fine, however
> > on reading Documentation/asm-annotations.rst it's not completely clear to
> > me when SYM_FUNC_START() should be used. In this case, for example, we are
> > *not* pushing a stackframe and that would appear to be at odds with the
> > documentation.
>
> > Jiri -- is it ok to omit the stack frame for leaf functions annotated with
> > SYM_FUNC_START? I'm guessing it should be, since the link register isn't
> > going to be clobbered. Could we update the documentation to reflect that?
>
> Yeah, the documentation isn't great on that. I was going on the basis
> of both trying to minimize changes to the generated output as part of
> the bulk change and looking at it from the point of view of the caller -
> if as in this case the caller thinks it's a regular C function it seems
> sensible to annotate it as such.
Maybe a small tweak to the documentation as per below, indicating that the
stack stuff is just an x86-specific example?
Jiri?
diff --git a/Documentation/asm-annotations.rst b/Documentation/asm-annotations.rst
index f55c2bb74d00..32ea57483378 100644
--- a/Documentation/asm-annotations.rst
+++ b/Documentation/asm-annotations.rst
@@ -73,10 +73,11 @@ The new macros are prefixed with the ``SYM_`` prefix and can be divided into
three main groups:
1. ``SYM_FUNC_*`` -- to annotate C-like functions. This means functions with
- standard C calling conventions, i.e. the stack contains a return address at
- the predefined place and a return from the function can happen in a
- standard way. When frame pointers are enabled, save/restore of frame
- pointer shall happen at the start/end of a function, respectively, too.
+ standard C calling conventions. For example, on x86, this means that the
+ stack contains a return address at the predefined place and a return from
+ the function can happen in a standard way. When frame pointers are enabled,
+ save/restore of frame pointer shall happen at the start/end of a function,
+ respectively, too.
Checking tools like ``objtool`` should ensure such marked functions conform
to these rules. The tools can also easily annotate these functions with
> > > --- a/arch/arm64/lib/memcpy.S
> > > +++ b/arch/arm64/lib/memcpy.S
> > > @@ -57,11 +57,11 @@
> > > .endm
> > >
> > > .weak memcpy
>
> > Hmm, any idea why we use .weak explicitly here? Maybe better off using
> > the proper macros now? (same applies to many of the other lib/ functions
> > you're touching)
>
> Nope, there's a whole bunch of stuff where what we're currently doing is
> a bit interesting and I'm a bit worried that we might be relying on some
> of it. My theory here was to do the bulk of the changes as a 1:1
> replacement so the generated output is as close as possible for any big
> changes and then do anything more detailed that isn't actually *needed*
> on top of that. It's looking like there'll also be some stuff that
> definitely changes the output going in as well, I was going to do those
> as individual patches so that it's easier to find any breakages that get
> introduced and so the big, repetitive changes don't have other stuff
> mixed in.
Fair enough, I'll queue these three with the minor naming change and you can
send extra stuff on top of that.
Cheers,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] arm64: mm: Use modern annotations for assembly functions
2020-01-08 12:17 ` Will Deacon
@ 2020-01-08 13:50 ` Mark Brown
2020-01-08 14:56 ` Will Deacon
0 siblings, 1 reply; 16+ messages in thread
From: Mark Brown @ 2020-01-08 13:50 UTC (permalink / raw)
To: Will Deacon; +Cc: Catalin Marinas, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 752 bytes --]
On Wed, Jan 08, 2020 at 12:17:17PM +0000, Will Deacon wrote:
> On Tue, Jan 07, 2020 at 04:42:34PM +0000, Mark Brown wrote:
> > We can eventually, there's more stuff coming (very soon) for kernel/ and
> > kvm/ - once those are in I've got a patch sitting ready to remove
> > ENDPIPROC. That's basically the only patch for any of this stuff with
> > any interdependencies so I'm sending stuff as it's ready.
> Hmm, but with this series applied I don't see any remaining users of
> ENDPIPROC. Or are you saying that there are new users in the pipeline?
Ah, you're right - I seem to have confused myself about what bit went
where in the series. I've got the patch deleting them, I can send that
if these get applied or include it in the next posting.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] arm64: mm: Use modern annotations for assembly functions
2020-01-08 13:50 ` Mark Brown
@ 2020-01-08 14:56 ` Will Deacon
0 siblings, 0 replies; 16+ messages in thread
From: Will Deacon @ 2020-01-08 14:56 UTC (permalink / raw)
To: Mark Brown; +Cc: Catalin Marinas, linux-arm-kernel
On Wed, Jan 08, 2020 at 01:50:59PM +0000, Mark Brown wrote:
> On Wed, Jan 08, 2020 at 12:17:17PM +0000, Will Deacon wrote:
> > On Tue, Jan 07, 2020 at 04:42:34PM +0000, Mark Brown wrote:
>
> > > We can eventually, there's more stuff coming (very soon) for kernel/ and
> > > kvm/ - once those are in I've got a patch sitting ready to remove
> > > ENDPIPROC. That's basically the only patch for any of this stuff with
> > > any interdependencies so I'm sending stuff as it's ready.
>
> > Hmm, but with this series applied I don't see any remaining users of
> > ENDPIPROC. Or are you saying that there are new users in the pipeline?
>
> Ah, you're right - I seem to have confused myself about what bit went
> where in the series. I've got the patch deleting them, I can send that
> if these get applied or include it in the next posting.
I've pushed the current bits here:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/asm-annotations
so please feel free to send stuff on top!
Thanks,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] arm64: lib: Use modern annotations for assembly functions
2020-01-08 12:29 ` Will Deacon
@ 2020-01-10 16:56 ` Jiri Slaby
2020-01-15 18:43 ` Will Deacon
0 siblings, 1 reply; 16+ messages in thread
From: Jiri Slaby @ 2020-01-10 16:56 UTC (permalink / raw)
To: Will Deacon, Mark Brown; +Cc: Catalin Marinas, linux-arm-kernel
On 08. 01. 20, 13:29, Will Deacon wrote:
> On Tue, Jan 07, 2020 at 05:47:41PM +0000, Mark Brown wrote:
>> On Tue, Jan 07, 2020 at 02:44:46PM +0000, Will Deacon wrote:
>>> Jiri -- is it ok to omit the stack frame for leaf functions annotated with
>>> SYM_FUNC_START? I'm guessing it should be, since the link register isn't
>>> going to be clobbered. Could we update the documentation to reflect that?
>>
>> Yeah, the documentation isn't great on that. I was going on the basis
>> of both trying to minimize changes to the generated output as part of
>> the bulk change and looking at it from the point of view of the caller -
>> if as in this case the caller thinks it's a regular C function it seems
>> sensible to annotate it as such.
>
> Maybe a small tweak to the documentation as per below, indicating that the
> stack stuff is just an x86-specific example?
>
> Jiri?
Yes, the text in the documentation was too x86-specific. Could you send
the below as a proper patch? Thanks.
> diff --git a/Documentation/asm-annotations.rst b/Documentation/asm-annotations.rst
> index f55c2bb74d00..32ea57483378 100644
> --- a/Documentation/asm-annotations.rst
> +++ b/Documentation/asm-annotations.rst
> @@ -73,10 +73,11 @@ The new macros are prefixed with the ``SYM_`` prefix and can be divided into
> three main groups:
>
> 1. ``SYM_FUNC_*`` -- to annotate C-like functions. This means functions with
> - standard C calling conventions, i.e. the stack contains a return address at
> - the predefined place and a return from the function can happen in a
> - standard way. When frame pointers are enabled, save/restore of frame
> - pointer shall happen at the start/end of a function, respectively, too.
> + standard C calling conventions. For example, on x86, this means that the
> + stack contains a return address at the predefined place and a return from
> + the function can happen in a standard way. When frame pointers are enabled,
> + save/restore of frame pointer shall happen at the start/end of a function,
> + respectively, too.
>
> Checking tools like ``objtool`` should ensure such marked functions conform
> to these rules. The tools can also easily annotate these functions with
thanks,
--
js
suse labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] arm64: lib: Use modern annotations for assembly functions
2020-01-10 16:56 ` Jiri Slaby
@ 2020-01-15 18:43 ` Will Deacon
0 siblings, 0 replies; 16+ messages in thread
From: Will Deacon @ 2020-01-15 18:43 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Catalin Marinas, Mark Brown, linux-arm-kernel
On Fri, Jan 10, 2020 at 05:56:22PM +0100, Jiri Slaby wrote:
> On 08. 01. 20, 13:29, Will Deacon wrote:
> > On Tue, Jan 07, 2020 at 05:47:41PM +0000, Mark Brown wrote:
> >> On Tue, Jan 07, 2020 at 02:44:46PM +0000, Will Deacon wrote:
> >>> Jiri -- is it ok to omit the stack frame for leaf functions annotated with
> >>> SYM_FUNC_START? I'm guessing it should be, since the link register isn't
> >>> going to be clobbered. Could we update the documentation to reflect that?
> >>
> >> Yeah, the documentation isn't great on that. I was going on the basis
> >> of both trying to minimize changes to the generated output as part of
> >> the bulk change and looking at it from the point of view of the caller -
> >> if as in this case the caller thinks it's a regular C function it seems
> >> sensible to annotate it as such.
> >
> > Maybe a small tweak to the documentation as per below, indicating that the
> > stack stuff is just an x86-specific example?
> >
> > Jiri?
>
> Yes, the text in the documentation was too x86-specific. Could you send
> the below as a proper patch? Thanks.
Sorry it took so long:
https://lkml.kernel.org/r/20200115184305.1187-1-will@kernel.org
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-01-15 18:43 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-06 19:58 [PATCH 0/3] arm64: Conversions to modern assembly annotations Mark Brown
2020-01-06 19:58 ` [PATCH 1/3] arm64: asm: Add new-style position independent function annotations Mark Brown
2020-01-07 14:44 ` Will Deacon
2020-01-07 16:45 ` Mark Brown
2020-01-06 19:58 ` [PATCH 2/3] arm64: lib: Use modern annotations for assembly functions Mark Brown
2020-01-07 14:44 ` Will Deacon
2020-01-07 17:47 ` Mark Brown
2020-01-08 12:29 ` Will Deacon
2020-01-10 16:56 ` Jiri Slaby
2020-01-15 18:43 ` Will Deacon
2020-01-06 19:58 ` [PATCH 3/3] arm64: mm: " Mark Brown
2020-01-07 14:43 ` Will Deacon
2020-01-07 16:42 ` Mark Brown
2020-01-08 12:17 ` Will Deacon
2020-01-08 13:50 ` Mark Brown
2020-01-08 14:56 ` Will Deacon
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.