Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1602045 > unrolled thread

Re: [RFC] linkage: new macros for functions and data

Started byIngo Molnar <mingo@kernel.org>
First post2017-03-16 09:10 +0100
Last post2017-03-20 13:40 +0100
Articles 20 on this page of 30 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [RFC] linkage: new macros for functions and data Ingo Molnar <mingo@kernel.org> - 2017-03-16 09:10 +0100
    Re: [RFC] linkage: new macros for functions and data Jiri Slaby <jslaby@suse.cz> - 2017-03-16 09:20 +0100
      [PATCH v2 07/10] x86: assembly, annotate aliases Jiri Slaby <jslaby@suse.cz> - 2017-03-20 13:40 +0100
      [PATCH v2 04/10] x86: boot, annotate functions properly Jiri Slaby <jslaby@suse.cz> - 2017-03-20 13:40 +0100
      [PATCH v2 09/10] x86: entry, annotate interrupt symbols properly Jiri Slaby <jslaby@suse.cz> - 2017-03-20 13:40 +0100
      [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions Jiri Slaby <jslaby@suse.cz> - 2017-03-20 13:40 +0100
        Re: [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions Josh Poimboeuf <jpoimboe@redhat.com> - 2017-03-21 15:50 +0100
          Re: [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions Ingo Molnar <mingo@kernel.org> - 2017-03-22 08:40 +0100
        Re: [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions Josh Poimboeuf <jpoimboe@redhat.com> - 2017-03-22 15:30 +0100
          Re: [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions Jiri Slaby <jslaby@suse.cz> - 2017-03-22 17:00 +0100
      [PATCH v2 05/10] x86: kernel+lib, annotate local functions Jiri Slaby <jslaby@suse.cz> - 2017-03-20 13:40 +0100
      [PATCH v2 08/10] x86: entry, annotate THUNKs Jiri Slaby <jslaby@suse.cz> - 2017-03-20 13:40 +0100
      [PATCH v2 06/10] x86: crypto, annotate local functions Jiri Slaby <jslaby@suse.cz> - 2017-03-20 13:40 +0100
      [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data Jiri Slaby <jslaby@suse.cz> - 2017-03-20 13:40 +0100
        Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START  for data Josh Poimboeuf <jpoimboe@redhat.com> - 2017-03-20 14:40 +0100
          Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for  data Jiri Slaby <jslaby@suse.cz> - 2017-03-20 16:50 +0100
            Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START  for data Josh Poimboeuf <jpoimboe@redhat.com> - 2017-03-20 17:10 +0100
        Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START  for data Pavel Machek <pavel@ucw.cz> - 2017-03-21 15:20 +0100
          Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START  for data Ingo Molnar <mingo@kernel.org> - 2017-03-22 08:30 +0100
            Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for  data Jiri Slaby <jslaby@suse.cz> - 2017-03-22 08:50 +0100
              Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START  for data Ingo Molnar <mingo@kernel.org> - 2017-03-22 08:50 +0100
                Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START  for data Josh Poimboeuf <jpoimboe@redhat.com> - 2017-03-22 15:20 +0100
                  Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for  data Jiri Slaby <jslaby@suse.cz> - 2017-03-22 16:10 +0100
                    Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START  for data Josh Poimboeuf <jpoimboe@redhat.com> - 2017-03-22 16:40 +0100
                  Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START  for data Ingo Molnar <mingo@kernel.org> - 2017-03-23 08:40 +0100
                    Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START  for data Josh Poimboeuf <jpoimboe@redhat.com> - 2017-03-23 14:30 +0100
          Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for  data Jiri Slaby <jslaby@suse.cz> - 2017-03-22 13:10 +0100
            Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START  for data Pavel Machek <pavel@ucw.cz> - 2017-03-22 17:00 +0100
      [RFC v2 10/10] x86: boot, extract efi_pe_entry from startup_64 Jiri Slaby <jslaby@suse.cz> - 2017-03-20 13:40 +0100
      [PATCH v2 01/10] linkage: new macros for assembler symbols Jiri Slaby <jslaby@suse.cz> - 2017-03-20 13:40 +0100

Page 1 of 2  [1] 2  Next page →


#1602045 — Re: [RFC] linkage: new macros for functions and data

FromIngo Molnar <mingo@kernel.org>
Date2017-03-16 09:10 +0100
SubjectRe: [RFC] linkage: new macros for functions and data
Message-ID<tlyDU-3Np-11@gated-at.bofh.it>
* Jiri Slaby <jslaby@suse.cz> wrote:

> SYM_LOCAL_ALIAS_START -- use where there are two local names for one code
> SYM_ALIAS_START -- use where there are two global names for one code
> SYM_LOCAL_FUNC_START -- use for local functions
> SYM_FUNCTION_START -- use for global functions
> SYM_WEAK_FUNC_START -- use for weak functions
> SYM_ALIAS_END -- the end of LOCALALIASed or ALIASed code
> SYM_FUNCTION_END -- the end of SYM_LOCAL_FUNC_START, SYM_FUNCTION_START, SYM_WEAK_FUNC_START, ...
> SYM_DATA_START -- global data symbol
> SYM_DATA_END -- the end of SYM_DATA_START symbol

This looks mostly good to me, with minor details:

- The mixed 'FUNC' and 'FUNCTION' naming looks a bit confusing - I'd pick one and
  use that consistently.

- I'd also make the START/END constructs look more symmetric, i.e. make the 
  attribute a postfix, not a prefix.

- In fact I'd make the 'alias' notion an attribute as well - what matters mostly 
  is that it's a function symbol, and that fact is lost from the SYM_ALIAS naming.

I.e. something like this:

	SYM_FUNCTION_START
	SYM_FUNCTION_START_WEAK
	SYM_FUNCTION_START_LOCAL
	SYM_FUNCTION_START_ALIAS
	SYM_FUNCTION_START_LOCAL_ALIAS
	...
	SYM_FUNCTION_END

	SYM_DATA_START
	SYM_DATA_END

Note how simple and structured looking the nomenclature is when grouped in such a 
way, how easy it is to verify at a glance, and how easy it is to extend with new 
postfixes.

( In theory we could also make the attributes a real macro argument in the future,
  should the number of attributes increase significantly. )

Does this look good to everyone?

Thanks,

	Ingo

[toc] | [next] | [standalone]


#1602062

FromJiri Slaby <jslaby@suse.cz>
Date2017-03-16 09:20 +0100
Message-ID<tlyNB-3TH-33@gated-at.bofh.it>
In reply to#1602045
On 03/16/2017, 09:02 AM, Ingo Molnar wrote:
> 
> * Jiri Slaby <jslaby@suse.cz> wrote:
> 
>> SYM_LOCAL_ALIAS_START -- use where there are two local names for one code
>> SYM_ALIAS_START -- use where there are two global names for one code
>> SYM_LOCAL_FUNC_START -- use for local functions
>> SYM_FUNCTION_START -- use for global functions
>> SYM_WEAK_FUNC_START -- use for weak functions
>> SYM_ALIAS_END -- the end of LOCALALIASed or ALIASed code
>> SYM_FUNCTION_END -- the end of SYM_LOCAL_FUNC_START, SYM_FUNCTION_START, SYM_WEAK_FUNC_START, ...
>> SYM_DATA_START -- global data symbol
>> SYM_DATA_END -- the end of SYM_DATA_START symbol
> 
> This looks mostly good to me, with minor details:
> 
> - The mixed 'FUNC' and 'FUNCTION' naming looks a bit confusing - I'd pick one and
>   use that consistently.

Of course, I did it later after sending the RFC. I stuck to FUNC.

...
> Does this look good to everyone?

Fine by me. I will send patches for that, so that you can comment on
that on real uses.

thanks,
-- 
js
suse labs

[toc] | [prev] | [next] | [standalone]


#1604467 — [PATCH v2 07/10] x86: assembly, annotate aliases

FromJiri Slaby <jslaby@suse.cz>
Date2017-03-20 13:40 +0100
Subject[PATCH v2 07/10] x86: assembly, annotate aliases
Message-ID<tn4Ln-4J7-3@gated-at.bofh.it>
In reply to#1602062
_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS,
and SYM_FUNC_END_ALIAS. This will make the tools generating the
debuginfo happy.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <x86@kernel.org>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com> [xen parts]
Cc: <linux-crypto@vger.kernel.org>
Cc: <xen-devel@lists.xenproject.org>
---
 arch/x86/crypto/aesni-intel_asm.S | 5 ++---
 arch/x86/lib/memcpy_64.S          | 4 ++--
 arch/x86/lib/memmove_64.S         | 4 ++--
 arch/x86/lib/memset_64.S          | 4 ++--
 arch/x86/xen/xen-asm_64.S         | 4 ++--
 5 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S
index 8913ea70323c..ea247bfed89d 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -1744,8 +1744,7 @@ ENDPROC(aesni_gcm_enc)
 #endif
 
 
-.align 4
-_key_expansion_128:
+SYM_FUNC_START_LOCAL_ALIAS(_key_expansion_128)
 SYM_FUNC_START_LOCAL(_key_expansion_256a)
 	pshufd $0b11111111, %xmm1, %xmm1
 	shufps $0b00010000, %xmm0, %xmm4
@@ -1756,8 +1755,8 @@ SYM_FUNC_START_LOCAL(_key_expansion_256a)
 	movaps %xmm0, (TKEYP)
 	add $0x10, TKEYP
 	ret
-ENDPROC(_key_expansion_128)
 ENDPROC(_key_expansion_256a)
+SYM_FUNC_END_ALIAS(_key_expansion_128)
 
 SYM_FUNC_START_LOCAL(_key_expansion_192a)
 	pshufd $0b01010101, %xmm1, %xmm1
diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S
index 779782f58324..2d6518b4dbd6 100644
--- a/arch/x86/lib/memcpy_64.S
+++ b/arch/x86/lib/memcpy_64.S
@@ -26,7 +26,7 @@
  * Output:
  * rax original destination
  */
-ENTRY(__memcpy)
+SYM_FUNC_START_ALIAS(__memcpy)
 ENTRY(memcpy)
 	ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \
 		      "jmp memcpy_erms", X86_FEATURE_ERMS
@@ -40,7 +40,7 @@ ENTRY(memcpy)
 	rep movsb
 	ret
 ENDPROC(memcpy)
-ENDPROC(__memcpy)
+SYM_FUNC_END_ALIAS(__memcpy)
 EXPORT_SYMBOL(memcpy)
 EXPORT_SYMBOL(__memcpy)
 
diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S
index 15de86cd15b0..d22af97e5b27 100644
--- a/arch/x86/lib/memmove_64.S
+++ b/arch/x86/lib/memmove_64.S
@@ -25,7 +25,7 @@
  */
 .weak memmove
 
-ENTRY(memmove)
+SYM_FUNC_START_ALIAS(memmove)
 ENTRY(__memmove)
 
 	/* Handle more 32 bytes in loop */
@@ -207,6 +207,6 @@ ENTRY(__memmove)
 13:
 	retq
 ENDPROC(__memmove)
-ENDPROC(memmove)
+SYM_FUNC_END_ALIAS(memmove)
 EXPORT_SYMBOL(__memmove)
 EXPORT_SYMBOL(memmove)
diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S
index 55b95db30a61..0d3a1d341e60 100644
--- a/arch/x86/lib/memset_64.S
+++ b/arch/x86/lib/memset_64.S
@@ -18,7 +18,7 @@
  *
  * rax   original destination
  */
-ENTRY(memset)
+SYM_FUNC_START_ALIAS(memset)
 ENTRY(__memset)
 	/*
 	 * Some CPUs support enhanced REP MOVSB/STOSB feature. It is recommended
@@ -42,8 +42,8 @@ ENTRY(__memset)
 	rep stosb
 	movq %r9,%rax
 	ret
-ENDPROC(memset)
 ENDPROC(__memset)
+SYM_FUNC_END_ALIAS(memset)
 EXPORT_SYMBOL(memset)
 EXPORT_SYMBOL(__memset)
 
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index 2a968c087269..b3bf662a4f6a 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -117,13 +117,13 @@ ENDPROC(xen_sysenter_target)
 
 #else /* !CONFIG_IA32_EMULATION */
 
-ENTRY(xen_syscall32_target)
+SYM_FUNC_START_ALIAS(xen_syscall32_target)
 ENTRY(xen_sysenter_target)
 	lea 16(%rsp), %rsp	/* strip %rcx, %r11 */
 	mov $-ENOSYS, %rax
 	pushq $0
 	jmp hypercall_iret
-ENDPROC(xen_syscall32_target)
 ENDPROC(xen_sysenter_target)
+SYM_FUNC_END_ALIAS(xen_syscall32_target)
 
 #endif	/* CONFIG_IA32_EMULATION */
-- 
2.12.0

[toc] | [prev] | [next] | [standalone]


#1604472 — [PATCH v2 04/10] x86: boot, annotate functions properly

FromJiri Slaby <jslaby@suse.cz>
Date2017-03-20 13:40 +0100
Subject[PATCH v2 04/10] x86: boot, annotate functions properly
Message-ID<tn4Ln-4J7-13@gated-at.bofh.it>
In reply to#1602062
1) GLOBAL is meant for global symbols, but not functions. Use
   SYM_FUNC_START which is dedicated for global functions.
2) Finish every function with SYM_FUNC_END.

Note that efi_pe_entry is not a start of a function, it is the middle of
startup_64 -- annotate as such.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: <x86@kernel.org>

---

The alternative to the startup_64 change would be to move efi_pe_entry
out of startup_64 which actually makes more sense, but I am afraid I
cannot test the result properly. See what it is now:
	.org 0x200
	ENTRY(startup_64)
	#ifdef CONFIG_EFI_STUB
		jmp     preferred_addr
	GLOBAL(efi_pe_entry)
		... ; a lot of assembly (efi_pe_entry)
		leaq    preferred_addr(%rax), %rax
		jmp     *%rax
	preferred_addr:
	#endif
		... ; a lot of assembly (startup_64)
	ENDPROC(startup_64)

What about:
	.org 0x200
	ENTRY(startup_64)
		... ; a lot of assembly (startup_64)
	ENDPROC(startup_64)

	#ifdef CONFIG_EFI_STUB
	ENTRY(efi_pe_entry)
		... ; a lot of assembly (efi_pe_entry)
		leaq    startup_64(%rax), %rax
		jmp     *%rax
	ENDPROC(efi_pe_entry)
	#endif
This solution is at the end of the series as RFC.
---
 arch/x86/boot/compressed/head_64.S |  3 ++-
 arch/x86/boot/copy.S               | 12 ++++++------
 arch/x86/boot/pmjump.S             |  4 ++--
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
index d2ae1f821e0c..6f037b3af204 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -250,7 +250,7 @@ ENTRY(startup_64)
 	 */
 	jmp	preferred_addr
 
-ENTRY(efi_pe_entry)
+SYM_FUNC_INNER_LABEL(efi_pe_entry)
 	movq	%rcx, efi64_config(%rip)	/* Handle */
 	movq	%rdx, efi64_config+8(%rip) /* EFI System table pointer */
 
@@ -369,6 +369,7 @@ preferred_addr:
  */
 	leaq	relocated(%rbx), %rax
 	jmp	*%rax
+SYM_FUNC_END(startup_64)
 
 #ifdef CONFIG_EFI_STUB
 	.org 0x390
diff --git a/arch/x86/boot/copy.S b/arch/x86/boot/copy.S
index 1eb7d298b47d..ef154c1ca14d 100644
--- a/arch/x86/boot/copy.S
+++ b/arch/x86/boot/copy.S
@@ -17,7 +17,7 @@
 	.code16
 	.text
 
-GLOBAL(memcpy)
+SYM_FUNC_START(memcpy)
 	pushw	%si
 	pushw	%di
 	movw	%ax, %di
@@ -33,7 +33,7 @@ GLOBAL(memcpy)
 	retl
 ENDPROC(memcpy)
 
-GLOBAL(memset)
+SYM_FUNC_START(memset)
 	pushw	%di
 	movw	%ax, %di
 	movzbl	%dl, %eax
@@ -48,7 +48,7 @@ GLOBAL(memset)
 	retl
 ENDPROC(memset)
 
-GLOBAL(copy_from_fs)
+SYM_FUNC_START(copy_from_fs)
 	pushw	%ds
 	pushw	%fs
 	popw	%ds
@@ -57,7 +57,7 @@ GLOBAL(copy_from_fs)
 	retl
 ENDPROC(copy_from_fs)
 
-GLOBAL(copy_to_fs)
+SYM_FUNC_START(copy_to_fs)
 	pushw	%es
 	pushw	%fs
 	popw	%es
@@ -67,7 +67,7 @@ GLOBAL(copy_to_fs)
 ENDPROC(copy_to_fs)
 
 #if 0 /* Not currently used, but can be enabled as needed */
-GLOBAL(copy_from_gs)
+SYM_FUNC_START(copy_from_gs)
 	pushw	%ds
 	pushw	%gs
 	popw	%ds
@@ -76,7 +76,7 @@ GLOBAL(copy_from_gs)
 	retl
 ENDPROC(copy_from_gs)
 
-GLOBAL(copy_to_gs)
+SYM_FUNC_START(copy_to_gs)
 	pushw	%es
 	pushw	%gs
 	popw	%es
diff --git a/arch/x86/boot/pmjump.S b/arch/x86/boot/pmjump.S
index 3e0edc6d2a20..5915510c7b51 100644
--- a/arch/x86/boot/pmjump.S
+++ b/arch/x86/boot/pmjump.S
@@ -23,7 +23,7 @@
 /*
  * void protected_mode_jump(u32 entrypoint, u32 bootparams);
  */
-GLOBAL(protected_mode_jump)
+SYM_FUNC_START(protected_mode_jump)
 	movl	%edx, %esi		# Pointer to boot_params table
 
 	xorl	%ebx, %ebx
@@ -48,7 +48,7 @@ ENDPROC(protected_mode_jump)
 
 	.code32
 	.section ".text32","ax"
-GLOBAL(in_pm32)
+SYM_FUNC_START(in_pm32)
 	# Set up data segments for flat 32-bit mode
 	movl	%ecx, %ds
 	movl	%ecx, %es
-- 
2.12.0

[toc] | [prev] | [next] | [standalone]


#1604474 — [PATCH v2 09/10] x86: entry, annotate interrupt symbols properly

FromJiri Slaby <jslaby@suse.cz>
Date2017-03-20 13:40 +0100
Subject[PATCH v2 09/10] x86: entry, annotate interrupt symbols properly
Message-ID<tn4Lo-4J7-25@gated-at.bofh.it>
In reply to#1602062
* annotate local common_interrupt properly by SYM_FUNC_START_LOCAL,
  given it already has SYM_FUNC_END later
* use SYM_FUNC_INNER_LABEL for native_iret as it is in the middle of
  common_interrupt function
* use SYM_FUNC_INNER_LABEL for native_irq_return_iret instead of
  explicit .globl and label

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <x86@kernel.org>
---
 arch/x86/entry/entry_64.S | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 3e523f8d7e7f..ee1bc5ebc88f 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -512,7 +512,7 @@ SYM_FUNC_END(irq_entries_start)
 	 * then jump to common_interrupt.
 	 */
 	.p2align CONFIG_X86_L1_CACHE_SHIFT
-common_interrupt:
+SYM_FUNC_START_LOCAL(common_interrupt)
 	ASM_CLAC
 	addq	$-0x80, (%rsp)			/* Adjust vector to [-256, -1] range */
 	interrupt do_IRQ
@@ -565,7 +565,7 @@ restore_c_regs_and_iret:
 	REMOVE_PT_GPREGS_FROM_STACK 8
 	INTERRUPT_RETURN
 
-ENTRY(native_iret)
+SYM_FUNC_INNER_LABEL(native_iret)
 	/*
 	 * Are we returning to a stack segment from the LDT?  Note: in
 	 * 64-bit mode SS:RSP on the exception stack is always valid.
@@ -575,8 +575,7 @@ ENTRY(native_iret)
 	jnz	native_irq_return_ldt
 #endif
 
-.global native_irq_return_iret
-native_irq_return_iret:
+SYM_FUNC_INNER_LABEL(native_irq_return_iret)
 	/*
 	 * This may fault.  Non-paranoid faults on return to userspace are
 	 * handled by fixup_bad_iret.  These include #SS, #GP, and #NP.
-- 
2.12.0

[toc] | [prev] | [next] | [standalone]


#1604479 — [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions

FromJiri Slaby <jslaby@suse.cz>
Date2017-03-20 13:40 +0100
Subject[PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions
Message-ID<tn4Lo-4J7-27@gated-at.bofh.it>
In reply to#1602062
Somewhere END was used to end a function, elsewhere, nothing was used.
So unify it and mark them all by SYM_FUNC_END.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <x86@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: <linux-pm@vger.kernel.org>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com> [xen parts]
Cc: <xen-devel@lists.xenproject.org>
---
 arch/x86/entry/entry_64.S            | 40 ++++++++++++++++++------------------
 arch/x86/entry/entry_64_compat.S     |  5 +++--
 arch/x86/kernel/mcount_64.S          | 12 ++++++-----
 arch/x86/power/hibernate_asm_64.S    |  2 ++
 arch/x86/realmode/rm/reboot.S        |  1 +
 arch/x86/realmode/rm/trampoline_64.S |  4 ++++
 arch/x86/realmode/rm/wakeup_asm.S    |  1 +
 arch/x86/xen/xen-asm_64.S            |  2 ++
 arch/x86/xen/xen-head.S              |  2 +-
 arch/x86/xen/xen-pvh.S               |  2 +-
 10 files changed, 42 insertions(+), 29 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index d2b2a2948ffe..3e523f8d7e7f 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -324,7 +324,7 @@ syscall_return_via_sysret:
 opportunistic_sysret_failed:
 	SWAPGS
 	jmp	restore_c_regs_and_iret
-END(entry_SYSCALL_64)
+SYM_FUNC_END(entry_SYSCALL_64)
 
 ENTRY(stub_ptregs_64)
 	/*
@@ -350,13 +350,13 @@ ENTRY(stub_ptregs_64)
 
 1:
 	jmp	*%rax				/* Called from C */
-END(stub_ptregs_64)
+SYM_FUNC_END(stub_ptregs_64)
 
 .macro ptregs_stub func
 ENTRY(ptregs_\func)
 	leaq	\func(%rip), %rax
 	jmp	stub_ptregs_64
-END(ptregs_\func)
+SYM_FUNC_END(ptregs_\func)
 .endm
 
 /* Instantiate ptregs_stub for each ptregs-using syscall */
@@ -399,7 +399,7 @@ ENTRY(__switch_to_asm)
 	popq	%rbp
 
 	jmp	__switch_to
-END(__switch_to_asm)
+SYM_FUNC_END(__switch_to_asm)
 
 /*
  * A newly forked process directly context switches into this address.
@@ -435,7 +435,7 @@ ENTRY(ret_from_fork)
 	 */
 	movq	$0, RAX(%rsp)
 	jmp	2b
-END(ret_from_fork)
+SYM_FUNC_END(ret_from_fork)
 
 /*
  * Build the entry stubs with some assembler magic.
@@ -450,7 +450,7 @@ ENTRY(irq_entries_start)
 	jmp	common_interrupt
 	.align	8
     .endr
-END(irq_entries_start)
+SYM_FUNC_END(irq_entries_start)
 
 /*
  * Interrupt entry/exit.
@@ -652,7 +652,7 @@ native_irq_return_ldt:
 	 */
 	jmp	native_irq_return_iret
 #endif
-END(common_interrupt)
+SYM_FUNC_END(common_interrupt)
 
 /*
  * APIC interrupts.
@@ -664,7 +664,7 @@ ENTRY(\sym)
 .Lcommon_\sym:
 	interrupt \do_sym
 	jmp	ret_from_intr
-END(\sym)
+SYM_FUNC_END(\sym)
 .endm
 
 #ifdef CONFIG_TRACING
@@ -830,7 +830,7 @@ ENTRY(\sym)
 
 	jmp	error_exit			/* %ebx: no swapgs flag */
 	.endif
-END(\sym)
+SYM_FUNC_END(\sym)
 .endm
 
 #ifdef CONFIG_TRACING
@@ -873,7 +873,7 @@ ENTRY(native_load_gs_index)
 	SWAPGS
 	popfq
 	ret
-END(native_load_gs_index)
+SYM_FUNC_END(native_load_gs_index)
 EXPORT_SYMBOL(native_load_gs_index)
 
 	_ASM_EXTABLE(.Lgs_change, bad_gs)
@@ -903,7 +903,7 @@ ENTRY(do_softirq_own_stack)
 	leaveq
 	decl	PER_CPU_VAR(irq_count)
 	ret
-END(do_softirq_own_stack)
+SYM_FUNC_END(do_softirq_own_stack)
 
 #ifdef CONFIG_XEN
 idtentry xen_hypervisor_callback xen_do_hypervisor_callback has_error_code=0
@@ -939,7 +939,7 @@ ENTRY(xen_do_hypervisor_callback)		/* do_hypervisor_callback(struct *pt_regs) */
 	call	xen_maybe_preempt_hcall
 #endif
 	jmp	error_exit
-END(xen_do_hypervisor_callback)
+SYM_FUNC_END(xen_do_hypervisor_callback)
 
 /*
  * Hypervisor uses this for application faults while it executes.
@@ -985,7 +985,7 @@ ENTRY(xen_failsafe_callback)
 	SAVE_EXTRA_REGS
 	ENCODE_FRAME_POINTER
 	jmp	error_exit
-END(xen_failsafe_callback)
+SYM_FUNC_END(xen_failsafe_callback)
 
 apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \
 	xen_hvm_callback_vector xen_evtchn_do_upcall
@@ -1036,7 +1036,7 @@ ENTRY(paranoid_entry)
 	SWAPGS
 	xorl	%ebx, %ebx
 1:	ret
-END(paranoid_entry)
+SYM_FUNC_END(paranoid_entry)
 
 /*
  * "Paranoid" exit path from exception stack.  This is invoked
@@ -1065,7 +1065,7 @@ paranoid_exit_restore:
 	RESTORE_C_REGS
 	REMOVE_PT_GPREGS_FROM_STACK 8
 	INTERRUPT_RETURN
-END(paranoid_exit)
+SYM_FUNC_END(paranoid_exit)
 
 /*
  * Save all registers in pt_regs, and switch gs if needed.
@@ -1147,7 +1147,7 @@ ENTRY(error_entry)
 	mov	%rax, %rsp
 	decl	%ebx
 	jmp	.Lerror_entry_from_usermode_after_swapgs
-END(error_entry)
+SYM_FUNC_END(error_entry)
 
 
 /*
@@ -1161,7 +1161,7 @@ ENTRY(error_exit)
 	testl	%ebx, %ebx
 	jnz	retint_kernel
 	jmp	retint_user
-END(error_exit)
+SYM_FUNC_END(error_exit)
 
 /* Runs on exception stack */
 ENTRY(nmi)
@@ -1509,12 +1509,12 @@ nmi_restore:
 	 * mode, so this cannot result in a fault.
 	 */
 	INTERRUPT_RETURN
-END(nmi)
+SYM_FUNC_END(nmi)
 
 ENTRY(ignore_sysret)
 	mov	$-ENOSYS, %eax
 	sysret
-END(ignore_sysret)
+SYM_FUNC_END(ignore_sysret)
 
 ENTRY(rewind_stack_do_exit)
 	/* Prevent any naive code from trying to unwind to our caller. */
@@ -1525,4 +1525,4 @@ ENTRY(rewind_stack_do_exit)
 
 	call	do_exit
 1:	jmp 1b
-END(rewind_stack_do_exit)
+SYM_FUNC_END(rewind_stack_do_exit)
diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S
index 73d7ff0b125c..9239f80e11ce 100644
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -262,7 +262,7 @@ sysret32_from_system_call:
 	movq	RSP-ORIG_RAX(%rsp), %rsp
 	swapgs
 	sysretl
-END(entry_SYSCALL_compat)
+SYM_FUNC_END(entry_SYSCALL_compat)
 
 /*
  * 32-bit legacy system call entry.
@@ -340,7 +340,7 @@ ENTRY(entry_INT80_compat)
 	TRACE_IRQS_ON
 	SWAPGS
 	jmp	restore_regs_and_iret
-END(entry_INT80_compat)
+SYM_FUNC_END(entry_INT80_compat)
 
 SYM_FUNC_START(stub32_clone)
 	/*
@@ -352,3 +352,4 @@ SYM_FUNC_START(stub32_clone)
 	 */
 	xchg	%r8, %rcx
 	jmp	sys_clone
+SYM_FUNC_END(stub32_clone)
diff --git a/arch/x86/kernel/mcount_64.S b/arch/x86/kernel/mcount_64.S
index 2b4d7045e823..f3b0cb57a8c7 100644
--- a/arch/x86/kernel/mcount_64.S
+++ b/arch/x86/kernel/mcount_64.S
@@ -152,7 +152,7 @@ EXPORT_SYMBOL(mcount)
 
 ENTRY(function_hook)
 	retq
-END(function_hook)
+SYM_FUNC_END(function_hook)
 
 ENTRY(ftrace_caller)
 	/* save_mcount_regs fills in first two parameters */
@@ -184,11 +184,12 @@ GLOBAL(ftrace_epilogue)
 GLOBAL(ftrace_graph_call)
 	jmp ftrace_stub
 #endif
+SYM_FUNC_END(ftrace_caller)
 
 /* This is weak to keep gas from relaxing the jumps */
 WEAK(ftrace_stub)
 	retq
-END(ftrace_caller)
+SYM_FUNC_END(ftrace_caller)
 
 ENTRY(ftrace_regs_caller)
 	/* Save the current flags before any operations that can change them */
@@ -259,7 +260,7 @@ GLOBAL(ftrace_regs_caller_end)
 
 	jmp ftrace_epilogue
 
-END(ftrace_regs_caller)
+SYM_FUNC_END(ftrace_regs_caller)
 
 
 #else /* ! CONFIG_DYNAMIC_FTRACE */
@@ -295,7 +296,7 @@ trace:
 	restore_mcount_regs
 
 	jmp fgraph_trace
-END(function_hook)
+SYM_FUNC_END(function_hook)
 #endif /* CONFIG_DYNAMIC_FTRACE */
 #endif /* CONFIG_FUNCTION_TRACER */
 
@@ -318,7 +319,7 @@ ENTRY(ftrace_graph_caller)
 	restore_mcount_regs
 
 	retq
-END(ftrace_graph_caller)
+SYM_FUNC_END(ftrace_graph_caller)
 
 SYM_FUNC_START(return_to_handler)
 	subq  $24, %rsp
@@ -335,4 +336,5 @@ SYM_FUNC_START(return_to_handler)
 	movq (%rsp), %rax
 	addq $24, %rsp
 	jmp *%rdi
+SYM_FUNC_END(return_to_handler)
 #endif
diff --git a/arch/x86/power/hibernate_asm_64.S b/arch/x86/power/hibernate_asm_64.S
index ce8da3a0412c..5b6eb95e1b7b 100644
--- a/arch/x86/power/hibernate_asm_64.S
+++ b/arch/x86/power/hibernate_asm_64.S
@@ -68,6 +68,7 @@ ENTRY(restore_image)
 	/* jump to relocated restore code */
 	movq	relocated_restore_code(%rip), %rcx
 	jmpq	*%rcx
+SYM_FUNC_END(restore_image)
 
 	/* code below has been relocated to a safe page */
 ENTRY(core_restore_code)
@@ -98,6 +99,7 @@ ENTRY(core_restore_code)
 .Ldone:
 	/* jump to the restore_registers address from the image header */
 	jmpq	*%r8
+SYM_FUNC_END(core_restore_code)
 
 	 /* code below belongs to the image kernel */
 	.align PAGE_SIZE
diff --git a/arch/x86/realmode/rm/reboot.S b/arch/x86/realmode/rm/reboot.S
index d66c607bdc58..3dec2ba4adc5 100644
--- a/arch/x86/realmode/rm/reboot.S
+++ b/arch/x86/realmode/rm/reboot.S
@@ -62,6 +62,7 @@ GLOBAL(machine_real_restart_paging_off)
 	movl	%ecx, %gs
 	movl	%ecx, %ss
 	ljmpw	$8, $1f
+SYM_FUNC_END(machine_real_restart_asm)
 
 /*
  * This is 16-bit protected mode code to disable paging and the cache,
diff --git a/arch/x86/realmode/rm/trampoline_64.S b/arch/x86/realmode/rm/trampoline_64.S
index dac7b20d2f9d..6869f1229c3a 100644
--- a/arch/x86/realmode/rm/trampoline_64.S
+++ b/arch/x86/realmode/rm/trampoline_64.S
@@ -79,6 +79,8 @@ ENTRY(trampoline_start)
 no_longmode:
 	hlt
 	jmp no_longmode
+SYM_FUNC_END(trampoline_start)
+
 #include "../kernel/verify_cpu.S"
 
 	.section ".text32","ax"
@@ -116,6 +118,7 @@ ENTRY(startup_32)
 	 * the new gdt/idt that has __KERNEL_CS with CS.L = 1.
 	 */
 	ljmpl	$__KERNEL_CS, $pa_startup_64
+SYM_FUNC_END(startup_32)
 
 	.section ".text64","ax"
 	.code64
@@ -123,6 +126,7 @@ ENTRY(startup_32)
 ENTRY(startup_64)
 	# Now jump into the kernel using virtual addresses
 	jmpq	*tr_start(%rip)
+SYM_FUNC_END(startup_64)
 
 	.section ".rodata","a"
 	# Duplicate the global descriptor table
diff --git a/arch/x86/realmode/rm/wakeup_asm.S b/arch/x86/realmode/rm/wakeup_asm.S
index 9e7e14797a72..b5f711327aef 100644
--- a/arch/x86/realmode/rm/wakeup_asm.S
+++ b/arch/x86/realmode/rm/wakeup_asm.S
@@ -134,6 +134,7 @@ ENTRY(wakeup_start)
 #else
 	jmp	trampoline_start
 #endif
+SYM_FUNC_END(wakeup_start)
 
 bogus_real_magic:
 1:
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index c3df43141e70..2a968c087269 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -49,6 +49,7 @@ ENTRY(xen_iret)
 1:	jmp hypercall_iret
 ENDPATCH(xen_iret)
 RELOC(xen_iret, 1b+1)
+SYM_FUNC_END(xen_iret)
 
 ENTRY(xen_sysret64)
 	/*
@@ -68,6 +69,7 @@ ENTRY(xen_sysret64)
 1:	jmp hypercall_iret
 ENDPATCH(xen_sysret64)
 RELOC(xen_sysret64, 1b+1)
+SYM_FUNC_END(xen_sysret64)
 
 /*
  * Xen handles syscall callbacks much like ordinary exceptions, which
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 37794e42b67d..f8b2371faf62 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -32,7 +32,7 @@ ENTRY(startup_xen)
 	mov $init_thread_union+THREAD_SIZE, %_ASM_SP
 
 	jmp xen_start_kernel
-
+SYM_FUNC_END(startup_xen)
 	__FINIT
 
 .pushsection .text
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
index 5e246716d58f..7dc332435c14 100644
--- a/arch/x86/xen/xen-pvh.S
+++ b/arch/x86/xen/xen-pvh.S
@@ -133,7 +133,7 @@ ENTRY(pvh_start_xen)
 
 	ljmp $__BOOT_CS, $_pa(startup_32)
 #endif
-END(pvh_start_xen)
+SYM_FUNC_END(pvh_start_xen)
 
 	.section ".init.data","aw"
 	.balign 8
-- 
2.12.0

[toc] | [prev] | [next] | [standalone]


#1605667 — Re: [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions

FromJosh Poimboeuf <jpoimboe@redhat.com>
Date2017-03-21 15:50 +0100
SubjectRe: [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions
Message-ID<tntgJ-4Dp-9@gated-at.bofh.it>
In reply to#1604479
On Mon, Mar 20, 2017 at 01:32:15PM +0100, Jiri Slaby wrote:
>  ENTRY(ftrace_caller)
>  	/* save_mcount_regs fills in first two parameters */
> @@ -184,11 +184,12 @@ GLOBAL(ftrace_epilogue)
>  GLOBAL(ftrace_graph_call)
>  	jmp ftrace_stub
>  #endif
> +SYM_FUNC_END(ftrace_caller)
>  
>  /* This is weak to keep gas from relaxing the jumps */
>  WEAK(ftrace_stub)
>  	retq
> -END(ftrace_caller)
> +SYM_FUNC_END(ftrace_caller)

This gives ftrace_caller() two ends.

-- 
Josh

[toc] | [prev] | [next] | [standalone]


#1606254 — Re: [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions

FromIngo Molnar <mingo@kernel.org>
Date2017-03-22 08:40 +0100
SubjectRe: [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions
Message-ID<tnJ2a-7gq-3@gated-at.bofh.it>
In reply to#1605667
* Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> On Mon, Mar 20, 2017 at 01:32:15PM +0100, Jiri Slaby wrote:
> >  ENTRY(ftrace_caller)
> >  	/* save_mcount_regs fills in first two parameters */
> > @@ -184,11 +184,12 @@ GLOBAL(ftrace_epilogue)
> >  GLOBAL(ftrace_graph_call)
> >  	jmp ftrace_stub
> >  #endif
> > +SYM_FUNC_END(ftrace_caller)
> >  
> >  /* This is weak to keep gas from relaxing the jumps */
> >  WEAK(ftrace_stub)
> >  	retq
> > -END(ftrace_caller)
> > +SYM_FUNC_END(ftrace_caller)
> 
> This gives ftrace_caller() two ends.

Such errors too could be detected automatically via objtool or some other symbol 
debug mechanism.

The reason it might be a good fit for objtool is to make the checking optional (no 
need to burden a regular build with it), plus objtool already looks at the .o from 
first principles - a symbol checking sub-functionality could analyze the symbol 
names in the same pass.

If we want to complicate things with CFI then we absolutely should increase the 
quality of our symbol names space.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]


#1606579 — Re: [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions

FromJosh Poimboeuf <jpoimboe@redhat.com>
Date2017-03-22 15:30 +0100
SubjectRe: [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions
Message-ID<tnPqX-3Kn-37@gated-at.bofh.it>
In reply to#1604479
On Mon, Mar 20, 2017 at 01:32:15PM +0100, Jiri Slaby wrote:
> Somewhere END was used to end a function, elsewhere, nothing was used.
> So unify it and mark them all by SYM_FUNC_END.
> 
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>

For me these patches would be easier to review if the SYM_FUNC_START and
SYM_FUNC_END pairs for a given function are done in the same patch.

Also I noticed several cases in entry_64.S where the old ENTRY macro is
still used, and paired with SYM_FUNC_END.

Maybe there should be an x86 version of the deprecated ENTRY/ENDPROC/etc
macros which throw a warning or an error?

-- 
Josh

[toc] | [prev] | [next] | [standalone]


#1606699 — Re: [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions

FromJiri Slaby <jslaby@suse.cz>
Date2017-03-22 17:00 +0100
SubjectRe: [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions
Message-ID<tnQQ3-4OP-65@gated-at.bofh.it>
In reply to#1606579
On 03/22/2017, 03:26 PM, Josh Poimboeuf wrote:
> On Mon, Mar 20, 2017 at 01:32:15PM +0100, Jiri Slaby wrote:
>> Somewhere END was used to end a function, elsewhere, nothing was used.
>> So unify it and mark them all by SYM_FUNC_END.
>>
>> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> 
> For me these patches would be easier to review if the SYM_FUNC_START and
> SYM_FUNC_END pairs for a given function are done in the same patch.

This patchset was intended to make everything paired with minimum
changes. I certainly can change also counter-elements of each
added/changed one if you prefer.

> Also I noticed several cases in entry_64.S where the old ENTRY macro is
> still used, and paired with SYM_FUNC_END.
> 
> Maybe there should be an x86 version of the deprecated ENTRY/ENDPROC/etc
> macros which throw a warning or an error?

Yes, my plan is to throw ENTRY/ENDPROC on the floor from x86 completely.
And I will do it after this patchset settles down by sed or something in
one shot (per directory or something).

thanks,
-- 
js
suse labs

[toc] | [prev] | [next] | [standalone]


#1604480 — [PATCH v2 05/10] x86: kernel+lib, annotate local functions

FromJiri Slaby <jslaby@suse.cz>
Date2017-03-20 13:40 +0100
Subject[PATCH v2 05/10] x86: kernel+lib, annotate local functions
Message-ID<tn4Lo-4J7-33@gated-at.bofh.it>
In reply to#1602062
Use the newly added SYM_FUNC_START_LOCAL to annotate starts of all
functions which do not have ".globl" annotation. This is needed to
balance SYM_FUNC_END for tools that are about to generate debuginfo.

In this patch, do it for local verify_cpu, early_idt_handler_common, and
bad_*_user properly.  Note that early_idt_handler_common already had
ENDPROC -- switch to the new SYM_FUNC_END.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <x86@kernel.org>
---
 arch/x86/kernel/head_64.S    | 4 ++--
 arch/x86/kernel/verify_cpu.S | 3 ++-
 arch/x86/lib/getuser.S       | 8 ++++----
 arch/x86/lib/putuser.S       | 4 ++--
 4 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index e093a804f1fb..90616ba150eb 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -355,7 +355,7 @@ ENTRY(early_idt_handler_array)
 	.endr
 ENDPROC(early_idt_handler_array)
 
-early_idt_handler_common:
+SYM_FUNC_START_LOCAL(early_idt_handler_common)
 	/*
 	 * The stack is the hardware frame, an error code or zero, and the
 	 * vector number.
@@ -396,7 +396,7 @@ early_idt_handler_common:
 20:
 	decl early_recursion_flag(%rip)
 	jmp restore_regs_and_iret
-ENDPROC(early_idt_handler_common)
+SYM_FUNC_END(early_idt_handler_common)
 
 	__INITDATA
 
diff --git a/arch/x86/kernel/verify_cpu.S b/arch/x86/kernel/verify_cpu.S
index 014ea59aa153..fd60f1ac5fec 100644
--- a/arch/x86/kernel/verify_cpu.S
+++ b/arch/x86/kernel/verify_cpu.S
@@ -33,7 +33,7 @@
 #include <asm/cpufeatures.h>
 #include <asm/msr-index.h>
 
-verify_cpu:
+SYM_FUNC_START_LOCAL(verify_cpu)
 	pushf				# Save caller passed flags
 	push	$0			# Kill any dangerous flags
 	popf
@@ -139,3 +139,4 @@ verify_cpu:
 	popf				# Restore caller passed flags
 	xorl %eax, %eax
 	ret
+SYM_FUNC_END(verify_cpu)
diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S
index 37b62d412148..29f0707a3913 100644
--- a/arch/x86/lib/getuser.S
+++ b/arch/x86/lib/getuser.S
@@ -104,21 +104,21 @@ ENDPROC(__get_user_8)
 EXPORT_SYMBOL(__get_user_8)
 
 
-bad_get_user:
+SYM_FUNC_START_LOCAL(bad_get_user)
 	xor %edx,%edx
 	mov $(-EFAULT),%_ASM_AX
 	ASM_CLAC
 	ret
-END(bad_get_user)
+SYM_FUNC_END(bad_get_user)
 
 #ifdef CONFIG_X86_32
-bad_get_user_8:
+SYM_FUNC_START_LOCAL(bad_get_user_8)
 	xor %edx,%edx
 	xor %ecx,%ecx
 	mov $(-EFAULT),%_ASM_AX
 	ASM_CLAC
 	ret
-END(bad_get_user_8)
+SYM_FUNC_END(bad_get_user_8)
 #endif
 
 	_ASM_EXTABLE(1b,bad_get_user)
diff --git a/arch/x86/lib/putuser.S b/arch/x86/lib/putuser.S
index cd5d716d2897..d77883f36875 100644
--- a/arch/x86/lib/putuser.S
+++ b/arch/x86/lib/putuser.S
@@ -88,10 +88,10 @@ ENTRY(__put_user_8)
 ENDPROC(__put_user_8)
 EXPORT_SYMBOL(__put_user_8)
 
-bad_put_user:
+SYM_FUNC_START_LOCAL(bad_put_user)
 	movl $-EFAULT,%eax
 	EXIT
-END(bad_put_user)
+SYM_FUNC_END(bad_put_user)
 
 	_ASM_EXTABLE(1b,bad_put_user)
 	_ASM_EXTABLE(2b,bad_put_user)
-- 
2.12.0

[toc] | [prev] | [next] | [standalone]


#1604481 — [PATCH v2 08/10] x86: entry, annotate THUNKs

FromJiri Slaby <jslaby@suse.cz>
Date2017-03-20 13:40 +0100
Subject[PATCH v2 08/10] x86: entry, annotate THUNKs
Message-ID<tn4Lo-4J7-29@gated-at.bofh.it>
In reply to#1602062
Place SYM_FUNC_START and SYM_FUNC_END around the THUNK macro body, given
it generates functions.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <x86@kernel.org>
---
 arch/x86/entry/thunk_64.S | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/entry/thunk_64.S b/arch/x86/entry/thunk_64.S
index be36bf4e0957..38b76f5b097d 100644
--- a/arch/x86/entry/thunk_64.S
+++ b/arch/x86/entry/thunk_64.S
@@ -12,9 +12,7 @@
 
 	/* rdi:	arg1 ... normal C conventions. rax is saved/restored. */
 	.macro THUNK name, func, put_ret_addr_in_rdi=0
-	.globl \name
-	.type \name, @function
-\name:
+SYM_FUNC_START(\name)
 	pushq %rbp
 	movq %rsp, %rbp
 
@@ -36,6 +34,7 @@
 	call \func
 	jmp  .L_restore
 	_ASM_NOKPROBE(\name)
+SYM_FUNC_END(\name)
 	.endm
 
 #ifdef CONFIG_TRACE_IRQFLAGS
-- 
2.12.0

[toc] | [prev] | [next] | [standalone]


#1604484 — [PATCH v2 06/10] x86: crypto, annotate local functions

FromJiri Slaby <jslaby@suse.cz>
Date2017-03-20 13:40 +0100
Subject[PATCH v2 06/10] x86: crypto, annotate local functions
Message-ID<tn4Lp-4J7-43@gated-at.bofh.it>
In reply to#1602062
Use the newly added SYM_FUNC_START_LOCAL to annotate starts of all
functions which do not have ".globl" annotation, but their ends are
annotated by ENDPROC. This is needed to balance ENDPROC for tools that
are about to generate debuginfo.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <x86@kernel.org>
Cc: <linux-crypto@vger.kernel.org>
---
 arch/x86/crypto/aesni-intel_asm.S            | 29 ++++++++++------------------
 arch/x86/crypto/camellia-aesni-avx-asm_64.S  | 10 +++++-----
 arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 10 +++++-----
 arch/x86/crypto/cast5-avx-x86_64-asm_64.S    |  4 ++--
 arch/x86/crypto/cast6-avx-x86_64-asm_64.S    |  4 ++--
 arch/x86/crypto/ghash-clmulni-intel_asm.S    |  2 +-
 arch/x86/crypto/serpent-avx-x86_64-asm_64.S  |  4 ++--
 arch/x86/crypto/serpent-avx2-asm_64.S        |  4 ++--
 arch/x86/crypto/twofish-avx-x86_64-asm_64.S  |  4 ++--
 9 files changed, 31 insertions(+), 40 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S
index 3c465184ff8a..8913ea70323c 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -1746,7 +1746,7 @@ ENDPROC(aesni_gcm_enc)
 
 .align 4
 _key_expansion_128:
-_key_expansion_256a:
+SYM_FUNC_START_LOCAL(_key_expansion_256a)
 	pshufd $0b11111111, %xmm1, %xmm1
 	shufps $0b00010000, %xmm0, %xmm4
 	pxor %xmm4, %xmm0
@@ -1759,8 +1759,7 @@ _key_expansion_256a:
 ENDPROC(_key_expansion_128)
 ENDPROC(_key_expansion_256a)
 
-.align 4
-_key_expansion_192a:
+SYM_FUNC_START_LOCAL(_key_expansion_192a)
 	pshufd $0b01010101, %xmm1, %xmm1
 	shufps $0b00010000, %xmm0, %xmm4
 	pxor %xmm4, %xmm0
@@ -1784,8 +1783,7 @@ _key_expansion_192a:
 	ret
 ENDPROC(_key_expansion_192a)
 
-.align 4
-_key_expansion_192b:
+SYM_FUNC_START_LOCAL(_key_expansion_192b)
 	pshufd $0b01010101, %xmm1, %xmm1
 	shufps $0b00010000, %xmm0, %xmm4
 	pxor %xmm4, %xmm0
@@ -1804,8 +1802,7 @@ _key_expansion_192b:
 	ret
 ENDPROC(_key_expansion_192b)
 
-.align 4
-_key_expansion_256b:
+SYM_FUNC_START_LOCAL(_key_expansion_256b)
 	pshufd $0b10101010, %xmm1, %xmm1
 	shufps $0b00010000, %xmm2, %xmm4
 	pxor %xmm4, %xmm2
@@ -1968,8 +1965,7 @@ ENDPROC(aesni_enc)
  *	KEY
  *	TKEYP (T1)
  */
-.align 4
-_aesni_enc1:
+SYM_FUNC_START_LOCAL(_aesni_enc1)
 	movaps (KEYP), KEY		# key
 	mov KEYP, TKEYP
 	pxor KEY, STATE		# round 0
@@ -2032,8 +2028,7 @@ ENDPROC(_aesni_enc1)
  *	KEY
  *	TKEYP (T1)
  */
-.align 4
-_aesni_enc4:
+SYM_FUNC_START_LOCAL(_aesni_enc4)
 	movaps (KEYP), KEY		# key
 	mov KEYP, TKEYP
 	pxor KEY, STATE1		# round 0
@@ -2160,8 +2155,7 @@ ENDPROC(aesni_dec)
  *	KEY
  *	TKEYP (T1)
  */
-.align 4
-_aesni_dec1:
+SYM_FUNC_START_LOCAL(_aesni_dec1)
 	movaps (KEYP), KEY		# key
 	mov KEYP, TKEYP
 	pxor KEY, STATE		# round 0
@@ -2224,8 +2218,7 @@ ENDPROC(_aesni_dec1)
  *	KEY
  *	TKEYP (T1)
  */
-.align 4
-_aesni_dec4:
+SYM_FUNC_START_LOCAL(_aesni_dec4)
 	movaps (KEYP), KEY		# key
 	mov KEYP, TKEYP
 	pxor KEY, STATE1		# round 0
@@ -2591,8 +2584,7 @@ ENDPROC(aesni_cbc_dec)
  *	INC:	== 1, in little endian
  *	BSWAP_MASK == endian swapping mask
  */
-.align 4
-_aesni_inc_init:
+SYM_FUNC_START_LOCAL(_aesni_inc_init)
 	movaps .Lbswap_mask, BSWAP_MASK
 	movaps IV, CTR
 	PSHUFB_XMM BSWAP_MASK CTR
@@ -2617,8 +2609,7 @@ ENDPROC(_aesni_inc_init)
  *	CTR:	== output IV, in little endian
  *	TCTR_LOW: == lower qword of CTR
  */
-.align 4
-_aesni_inc:
+SYM_FUNC_START_LOCAL(_aesni_inc)
 	paddq INC, CTR
 	add $1, TCTR_LOW
 	jnc .Linc_low
diff --git a/arch/x86/crypto/camellia-aesni-avx-asm_64.S b/arch/x86/crypto/camellia-aesni-avx-asm_64.S
index f7c495e2863c..5964d98c4448 100644
--- a/arch/x86/crypto/camellia-aesni-avx-asm_64.S
+++ b/arch/x86/crypto/camellia-aesni-avx-asm_64.S
@@ -188,7 +188,7 @@
  * larger and would only be 0.5% faster (on sandy-bridge).
  */
 .align 8
-roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd:
+SYM_FUNC_START_LOCAL(roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd)
 	roundsm16(%xmm0, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7,
 		  %xmm8, %xmm9, %xmm10, %xmm11, %xmm12, %xmm13, %xmm14, %xmm15,
 		  %rcx, (%r9));
@@ -196,7 +196,7 @@ roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd:
 ENDPROC(roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd)
 
 .align 8
-roundsm16_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab:
+SYM_FUNC_START_LOCAL(roundsm16_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab)
 	roundsm16(%xmm4, %xmm5, %xmm6, %xmm7, %xmm0, %xmm1, %xmm2, %xmm3,
 		  %xmm12, %xmm13, %xmm14, %xmm15, %xmm8, %xmm9, %xmm10, %xmm11,
 		  %rax, (%r9));
@@ -721,7 +721,7 @@ ENDPROC(roundsm16_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab)
 .text
 
 .align 8
-__camellia_enc_blk16:
+SYM_FUNC_START_LOCAL(__camellia_enc_blk16)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	%rax: temporary storage, 256 bytes
@@ -808,7 +808,7 @@ __camellia_enc_blk16:
 ENDPROC(__camellia_enc_blk16)
 
 .align 8
-__camellia_dec_blk16:
+SYM_FUNC_START_LOCAL(__camellia_dec_blk16)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	%rax: temporary storage, 256 bytes
@@ -1119,7 +1119,7 @@ ENDPROC(camellia_ctr_16way)
 	vpxor tmp, iv, iv;
 
 .align 8
-camellia_xts_crypt_16way:
+SYM_FUNC_START_LOCAL(camellia_xts_crypt_16way)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	%rsi: dst (16 blocks)
diff --git a/arch/x86/crypto/camellia-aesni-avx2-asm_64.S b/arch/x86/crypto/camellia-aesni-avx2-asm_64.S
index eee5b3982cfd..b3dc6fd6868a 100644
--- a/arch/x86/crypto/camellia-aesni-avx2-asm_64.S
+++ b/arch/x86/crypto/camellia-aesni-avx2-asm_64.S
@@ -227,7 +227,7 @@
  * larger and would only marginally faster.
  */
 .align 8
-roundsm32_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd:
+SYM_FUNC_START_LOCAL(roundsm32_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd)
 	roundsm32(%ymm0, %ymm1, %ymm2, %ymm3, %ymm4, %ymm5, %ymm6, %ymm7,
 		  %ymm8, %ymm9, %ymm10, %ymm11, %ymm12, %ymm13, %ymm14, %ymm15,
 		  %rcx, (%r9));
@@ -235,7 +235,7 @@ roundsm32_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd:
 ENDPROC(roundsm32_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd)
 
 .align 8
-roundsm32_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab:
+SYM_FUNC_START_LOCAL(roundsm32_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab)
 	roundsm32(%ymm4, %ymm5, %ymm6, %ymm7, %ymm0, %ymm1, %ymm2, %ymm3,
 		  %ymm12, %ymm13, %ymm14, %ymm15, %ymm8, %ymm9, %ymm10, %ymm11,
 		  %rax, (%r9));
@@ -764,7 +764,7 @@ ENDPROC(roundsm32_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab)
 .text
 
 .align 8
-__camellia_enc_blk32:
+SYM_FUNC_START_LOCAL(__camellia_enc_blk32)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	%rax: temporary storage, 512 bytes
@@ -851,7 +851,7 @@ __camellia_enc_blk32:
 ENDPROC(__camellia_enc_blk32)
 
 .align 8
-__camellia_dec_blk32:
+SYM_FUNC_START_LOCAL(__camellia_dec_blk32)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	%rax: temporary storage, 512 bytes
@@ -1226,7 +1226,7 @@ ENDPROC(camellia_ctr_32way)
 	vpxor tmp1, iv, iv;
 
 .align 8
-camellia_xts_crypt_32way:
+SYM_FUNC_START_LOCAL(camellia_xts_crypt_32way)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	%rsi: dst (32 blocks)
diff --git a/arch/x86/crypto/cast5-avx-x86_64-asm_64.S b/arch/x86/crypto/cast5-avx-x86_64-asm_64.S
index b4a8806234ea..eb99d6b810f7 100644
--- a/arch/x86/crypto/cast5-avx-x86_64-asm_64.S
+++ b/arch/x86/crypto/cast5-avx-x86_64-asm_64.S
@@ -224,7 +224,7 @@
 .text
 
 .align 16
-__cast5_enc_blk16:
+SYM_FUNC_START_LOCAL(__cast5_enc_blk16)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	RL1: blocks 1 and 2
@@ -296,7 +296,7 @@ __cast5_enc_blk16:
 ENDPROC(__cast5_enc_blk16)
 
 .align 16
-__cast5_dec_blk16:
+SYM_FUNC_START_LOCAL(__cast5_dec_blk16)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	RL1: encrypted blocks 1 and 2
diff --git a/arch/x86/crypto/cast6-avx-x86_64-asm_64.S b/arch/x86/crypto/cast6-avx-x86_64-asm_64.S
index 952d3156a933..4f15c83e0118 100644
--- a/arch/x86/crypto/cast6-avx-x86_64-asm_64.S
+++ b/arch/x86/crypto/cast6-avx-x86_64-asm_64.S
@@ -262,7 +262,7 @@
 .text
 
 .align 8
-__cast6_enc_blk8:
+SYM_FUNC_START_LOCAL(__cast6_enc_blk8)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	RA1, RB1, RC1, RD1, RA2, RB2, RC2, RD2: blocks
@@ -308,7 +308,7 @@ __cast6_enc_blk8:
 ENDPROC(__cast6_enc_blk8)
 
 .align 8
-__cast6_dec_blk8:
+SYM_FUNC_START_LOCAL(__cast6_dec_blk8)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	RA1, RB1, RC1, RD1, RA2, RB2, RC2, RD2: encrypted blocks
diff --git a/arch/x86/crypto/ghash-clmulni-intel_asm.S b/arch/x86/crypto/ghash-clmulni-intel_asm.S
index f94375a8dcd1..6d5d80074394 100644
--- a/arch/x86/crypto/ghash-clmulni-intel_asm.S
+++ b/arch/x86/crypto/ghash-clmulni-intel_asm.S
@@ -47,7 +47,7 @@
  *	T2
  *	T3
  */
-__clmul_gf128mul_ble:
+SYM_FUNC_START_LOCAL(__clmul_gf128mul_ble)
 	movaps DATA, T1
 	pshufd $0b01001110, DATA, T2
 	pshufd $0b01001110, SHASH, T3
diff --git a/arch/x86/crypto/serpent-avx-x86_64-asm_64.S b/arch/x86/crypto/serpent-avx-x86_64-asm_64.S
index 2925077f8c6a..8301f918c50f 100644
--- a/arch/x86/crypto/serpent-avx-x86_64-asm_64.S
+++ b/arch/x86/crypto/serpent-avx-x86_64-asm_64.S
@@ -570,7 +570,7 @@
 	transpose_4x4(x0, x1, x2, x3, t0, t1, t2)
 
 .align 8
-__serpent_enc_blk8_avx:
+SYM_FUNC_START_LOCAL(__serpent_enc_blk8_avx)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	RA1, RB1, RC1, RD1, RA2, RB2, RC2, RD2: blocks
@@ -624,7 +624,7 @@ __serpent_enc_blk8_avx:
 ENDPROC(__serpent_enc_blk8_avx)
 
 .align 8
-__serpent_dec_blk8_avx:
+SYM_FUNC_START_LOCAL(__serpent_dec_blk8_avx)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	RA1, RB1, RC1, RD1, RA2, RB2, RC2, RD2: encrypted blocks
diff --git a/arch/x86/crypto/serpent-avx2-asm_64.S b/arch/x86/crypto/serpent-avx2-asm_64.S
index d67888f2a52a..b011a7ff1d9c 100644
--- a/arch/x86/crypto/serpent-avx2-asm_64.S
+++ b/arch/x86/crypto/serpent-avx2-asm_64.S
@@ -566,7 +566,7 @@
 	transpose_4x4(x0, x1, x2, x3, t0, t1, t2)
 
 .align 8
-__serpent_enc_blk16:
+SYM_FUNC_START_LOCAL(__serpent_enc_blk16)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	RA1, RB1, RC1, RD1, RA2, RB2, RC2, RD2: plaintext
@@ -620,7 +620,7 @@ __serpent_enc_blk16:
 ENDPROC(__serpent_enc_blk16)
 
 .align 8
-__serpent_dec_blk16:
+SYM_FUNC_START_LOCAL(__serpent_dec_blk16)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	RA1, RB1, RC1, RD1, RA2, RB2, RC2, RD2: ciphertext
diff --git a/arch/x86/crypto/twofish-avx-x86_64-asm_64.S b/arch/x86/crypto/twofish-avx-x86_64-asm_64.S
index b3f49d286348..cf771166b04a 100644
--- a/arch/x86/crypto/twofish-avx-x86_64-asm_64.S
+++ b/arch/x86/crypto/twofish-avx-x86_64-asm_64.S
@@ -249,7 +249,7 @@
 	vpxor		x3, wkey, x3;
 
 .align 8
-__twofish_enc_blk8:
+SYM_FUNC_START_LOCAL(__twofish_enc_blk8)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	RA1, RB1, RC1, RD1, RA2, RB2, RC2, RD2: blocks
@@ -291,7 +291,7 @@ __twofish_enc_blk8:
 ENDPROC(__twofish_enc_blk8)
 
 .align 8
-__twofish_dec_blk8:
+SYM_FUNC_START_LOCAL(__twofish_dec_blk8)
 	/* input:
 	 *	%rdi: ctx, CTX
 	 *	RC1, RD1, RA1, RB1, RC2, RD2, RA2, RB2: encrypted blocks
-- 
2.12.0

[toc] | [prev] | [next] | [standalone]


#1604485 — [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

FromJiri Slaby <jslaby@suse.cz>
Date2017-03-20 13:40 +0100
Subject[PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data
Message-ID<tn4Lp-4J7-47@gated-at.bofh.it>
In reply to#1602062
This is a start of series to cleanup macros used for starting functions,
data, globals etc. across x86. When we have all this sorted out, this
will help to inject DWARF unwinding info by objtool later.

The goal is forcing SYM_FUNC_START to emit .cfi_startproc and
SYM_FUNC_END to emit .cfi_endproc. Automatically at best.

This particular patch makes proper use of SYM_DATA_START on data and
SYM_FUNC_START on a function which was not the case on 4 locations.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <x86@kernel.org>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com> [xen parts]
Cc: <xen-devel@lists.xenproject.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: <linux-pm@vger.kernel.org>
---
 arch/x86/entry/entry_64_compat.S |  3 +--
 arch/x86/kernel/acpi/wakeup_64.S | 14 +++++++-------
 arch/x86/kernel/head_64.S        |  2 +-
 arch/x86/kernel/mcount_64.S      |  2 +-
 4 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S
index e1721dafbcb1..73d7ff0b125c 100644
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -342,8 +342,7 @@ ENTRY(entry_INT80_compat)
 	jmp	restore_regs_and_iret
 END(entry_INT80_compat)
 
-	ALIGN
-GLOBAL(stub32_clone)
+SYM_FUNC_START(stub32_clone)
 	/*
 	 * The 32-bit clone ABI is: clone(..., int tls_val, int *child_tidptr).
 	 * The 64-bit clone ABI is: clone(..., int *child_tidptr, int tls_val).
diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
index 50b8ed0317a3..0b5a5573f57d 100644
--- a/arch/x86/kernel/acpi/wakeup_64.S
+++ b/arch/x86/kernel/acpi/wakeup_64.S
@@ -125,12 +125,12 @@ ENTRY(do_suspend_lowlevel)
 ENDPROC(do_suspend_lowlevel)
 
 .data
-ENTRY(saved_rbp)	.quad	0
-ENTRY(saved_rsi)	.quad	0
-ENTRY(saved_rdi)	.quad	0
-ENTRY(saved_rbx)	.quad	0
+SYM_DATA_START(saved_rbp)		.quad	0
+SYM_DATA_START(saved_rsi)		.quad	0
+SYM_DATA_START(saved_rdi)		.quad	0
+SYM_DATA_START(saved_rbx)		.quad	0
 
-ENTRY(saved_rip)	.quad	0
-ENTRY(saved_rsp)	.quad	0
+SYM_DATA_START(saved_rip)		.quad	0
+SYM_DATA_START(saved_rsp)		.quad	0
 
-ENTRY(saved_magic)	.quad	0
+SYM_DATA_START(saved_magic)	.quad	0
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index ac9d327d2e42..e093a804f1fb 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -487,7 +487,7 @@ early_gdt_descr:
 early_gdt_descr_base:
 	.quad	INIT_PER_CPU_VAR(gdt_page)
 
-ENTRY(phys_base)
+SYM_DATA_START(phys_base)
 	/* This must match the first entry in level2_kernel_pgt */
 	.quad   0x0000000000000000
 EXPORT_SYMBOL(phys_base)
diff --git a/arch/x86/kernel/mcount_64.S b/arch/x86/kernel/mcount_64.S
index 7b0d3da52fb4..2b4d7045e823 100644
--- a/arch/x86/kernel/mcount_64.S
+++ b/arch/x86/kernel/mcount_64.S
@@ -320,7 +320,7 @@ ENTRY(ftrace_graph_caller)
 	retq
 END(ftrace_graph_caller)
 
-GLOBAL(return_to_handler)
+SYM_FUNC_START(return_to_handler)
 	subq  $24, %rsp
 
 	/* Save the return values */
-- 
2.12.0

[toc] | [prev] | [next] | [standalone]


#1604576 — Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

FromJosh Poimboeuf <jpoimboe@redhat.com>
Date2017-03-20 14:40 +0100
SubjectRe: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data
Message-ID<tn5Hs-5ly-27@gated-at.bofh.it>
In reply to#1604485
On Mon, Mar 20, 2017 at 01:32:14PM +0100, Jiri Slaby wrote:
> This is a start of series to cleanup macros used for starting functions,
> data, globals etc. across x86. When we have all this sorted out, this
> will help to inject DWARF unwinding info by objtool later.
> 
> The goal is forcing SYM_FUNC_START to emit .cfi_startproc and
> SYM_FUNC_END to emit .cfi_endproc. Automatically at best.

Do we still want to emit .cfi_startproc/endproc from the macro?  From
our last discussion, that seemed to be up in the air.

  https://lkml.kernel.org/r/20170217211804.j6l2d7t5mfzqzmbt@treble

What did you think about making CFI read-only for .c object files and
write-only for .S object files?

-- 
Josh

[toc] | [prev] | [next] | [standalone]


#1604701 — Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

FromJiri Slaby <jslaby@suse.cz>
Date2017-03-20 16:50 +0100
SubjectRe: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data
Message-ID<tn7Jf-6KZ-3@gated-at.bofh.it>
In reply to#1604576
On 03/20/2017, 02:32 PM, Josh Poimboeuf wrote:
> On Mon, Mar 20, 2017 at 01:32:14PM +0100, Jiri Slaby wrote:
>> This is a start of series to cleanup macros used for starting functions,
>> data, globals etc. across x86. When we have all this sorted out, this
>> will help to inject DWARF unwinding info by objtool later.
>>
>> The goal is forcing SYM_FUNC_START to emit .cfi_startproc and
>> SYM_FUNC_END to emit .cfi_endproc. Automatically at best.
> 
> Do we still want to emit .cfi_startproc/endproc from the macro?  From
> our last discussion, that seemed to be up in the air.
> 
>   https://lkml.kernel.org/r/20170217211804.j6l2d7t5mfzqzmbt@treble

"Automatically at best" above means "completely from objtool". I am
still uncertain whether it will work 100% or we would have to help by
generating some pieces from the added macros. In particular, the ALIASes
are evil which cause harm here:

fun_alias:
fun:
<code>
.size fun, .-fun
.type fun STT_FUNC
.size fun_alias, .-fun_alias
.type fun_alias STT_FUNC

Both cannot create (overlapping) .cfi_startproc/endproc, only the inner
shall.

But it seems so far, that we might be able to deal with all of that from
objtool... (I have not been thinking about this particular thing deep
enough yet.) Some sort of "from the last label that is marked as
STT_FUNC till its .size" might work.

> What did you think about making CFI read-only for .c object files and
> write-only for .S object files?

There are those functions like sync_core() or native_save_fl() with
inline asm. And they seem to need a) read-write support, or b) manual
annotation. I would like to avoid b) for sure.

thanks,
-- 
js
suse labs

[toc] | [prev] | [next] | [standalone]


#1604725 — Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

FromJosh Poimboeuf <jpoimboe@redhat.com>
Date2017-03-20 17:10 +0100
SubjectRe: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data
Message-ID<tn82C-77f-21@gated-at.bofh.it>
In reply to#1604701
On Mon, Mar 20, 2017 at 04:32:09PM +0100, Jiri Slaby wrote:
> On 03/20/2017, 02:32 PM, Josh Poimboeuf wrote:
> > On Mon, Mar 20, 2017 at 01:32:14PM +0100, Jiri Slaby wrote:
> >> This is a start of series to cleanup macros used for starting functions,
> >> data, globals etc. across x86. When we have all this sorted out, this
> >> will help to inject DWARF unwinding info by objtool later.
> >>
> >> The goal is forcing SYM_FUNC_START to emit .cfi_startproc and
> >> SYM_FUNC_END to emit .cfi_endproc. Automatically at best.
> > 
> > Do we still want to emit .cfi_startproc/endproc from the macro?  From
> > our last discussion, that seemed to be up in the air.
> > 
> >   https://lkml.kernel.org/r/20170217211804.j6l2d7t5mfzqzmbt@treble
> 
> "Automatically at best" above means "completely from objtool". I am
> still uncertain whether it will work 100% or we would have to help by
> generating some pieces from the added macros. In particular, the ALIASes
> are evil which cause harm here:
> 
> fun_alias:
> fun:
> <code>
> .size fun, .-fun
> .type fun STT_FUNC
> .size fun_alias, .-fun_alias
> .type fun_alias STT_FUNC
> 
> Both cannot create (overlapping) .cfi_startproc/endproc, only the inner
> shall.
> 
> But it seems so far, that we might be able to deal with all of that from
> objtool... (I have not been thinking about this particular thing deep
> enough yet.) Some sort of "from the last label that is marked as
> STT_FUNC till its .size" might work.

Ok.

> > What did you think about making CFI read-only for .c object files and
> > write-only for .S object files?
> 
> There are those functions like sync_core() or native_save_fl() with
> inline asm. And they seem to need a) read-write support, or b) manual
> annotation. I would like to avoid b) for sure.

Ah, so I guess those inline asm functions cause problems because they
muck with the stack pointer with pushes and pops?

I don't think manual annotation of inline asm would be so bad.  IIUC, it
would only mean replacing the pushes and pops with a macro which does
the CFI-annotated version, like PUSH_CFI and POP_CFI.  And the benefit
would be that objtool doesn't have to try to rewrite a bunch of .c
object files.

Objtool read-write worries me because it gives more responsibility to
objtool.  It could be tricky to insert CFI instructions within the ones
already created by gcc.  Also, while unlikely, a bug in objtool could
theoretically corrupt an object file and brick the kernel.  Also I
wonder how all those extra file writes would affect build performance.

If at all possible, I would rather objtool stay out of the way of the
compiler and let gcc do its job of generating CFI.

-- 
Josh

[toc] | [prev] | [next] | [standalone]


#1605635 — Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

FromPavel Machek <pavel@ucw.cz>
Date2017-03-21 15:20 +0100
SubjectRe: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data
Message-ID<tnsNI-4r2-11@gated-at.bofh.it>
In reply to#1604485

[Multipart message — attachments visible in raw view] — view raw

Hi!

> -ENTRY(saved_rbp)	.quad	0
> -ENTRY(saved_rsi)	.quad	0
> -ENTRY(saved_rdi)	.quad	0
> -ENTRY(saved_rbx)	.quad	0
> +SYM_DATA_START(saved_rbp)		.quad	0
> +SYM_DATA_START(saved_rsi)		.quad	0
> +SYM_DATA_START(saved_rdi)		.quad	0
> +SYM_DATA_START(saved_rbx)		.quad	0

Does it make sense to call it SYM_DATA_*START* when there's no
corresponding end?

Plus... it looks like saved_rsi (and friends) are only used inside
wakeup_64.S. Could we just delete the "ENTRY" annotations?

Thanks,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]


#1606250 — Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

FromIngo Molnar <mingo@kernel.org>
Date2017-03-22 08:30 +0100
SubjectRe: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data
Message-ID<tnISt-7c5-11@gated-at.bofh.it>
In reply to#1605635
* Pavel Machek <pavel@ucw.cz> wrote:

> Hi!
> 
> > -ENTRY(saved_rbp)	.quad	0
> > -ENTRY(saved_rsi)	.quad	0
> > -ENTRY(saved_rdi)	.quad	0
> > -ENTRY(saved_rbx)	.quad	0
> > +SYM_DATA_START(saved_rbp)		.quad	0
> > +SYM_DATA_START(saved_rsi)		.quad	0
> > +SYM_DATA_START(saved_rdi)		.quad	0
> > +SYM_DATA_START(saved_rbx)		.quad	0
> 
> Does it make sense to call it SYM_DATA_*START* when there's no
> corresponding end?

That looks like a bug - I think we should strive for them to always be in pairs.

Jiri, Josh, could objtool help here perhaps, to detect 'non-terminated' 
SYM_*_START() uses? This could be done by emitting debug data into a special 
section and then analyzing that section for unpaired entries. The section can be 
discarded in the final link, it won't show up in the kernel image.

We don't ever nest symbols, right?

> Plus... it looks like saved_rsi (and friends) are only used inside
> wakeup_64.S. Could we just delete the "ENTRY" annotations?

That appears to make sense as well.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]


#1606263 — Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

FromJiri Slaby <jslaby@suse.cz>
Date2017-03-22 08:50 +0100
SubjectRe: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data
Message-ID<tnJbP-7m2-1@gated-at.bofh.it>
In reply to#1606250
On 03/22/2017, 08:25 AM, Ingo Molnar wrote:
> 
> * Pavel Machek <pavel@ucw.cz> wrote:
> 
>> Hi!
>>
>>> -ENTRY(saved_rbp)	.quad	0
>>> -ENTRY(saved_rsi)	.quad	0
>>> -ENTRY(saved_rdi)	.quad	0
>>> -ENTRY(saved_rbx)	.quad	0
>>> +SYM_DATA_START(saved_rbp)		.quad	0
>>> +SYM_DATA_START(saved_rsi)		.quad	0
>>> +SYM_DATA_START(saved_rdi)		.quad	0
>>> +SYM_DATA_START(saved_rbx)		.quad	0
>>
>> Does it make sense to call it SYM_DATA_*START* when there's no
>> corresponding end?
> 
> That looks like a bug - I think we should strive for them to always be in pairs.
> 
> Jiri, Josh, could objtool help here perhaps, to detect 'non-terminated' 
> SYM_*_START() uses? This could be done by emitting debug data into a special 
> section and then analyzing that section for unpaired entries. The section can be 
> discarded in the final link, it won't show up in the kernel image.

It should be easier than that. No introduction of other info needed --
every global symbol without a ".type" or ".size" (i.e. SYM_*_END) should
be a bug now.

> We don't ever nest symbols, right?

AFAI could see so far, correct.

>> Plus... it looks like saved_rsi (and friends) are only used inside
>> wakeup_64.S. Could we just delete the "ENTRY" annotations?
> 
> That appears to make sense as well.

+1, will fix this.

thanks,
-- 
js
suse labs

[toc] | [prev] | [next] | [standalone]


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel


csiph-web