lkml.org 
[lkml]   [2017]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] x86/head_64.S: Rename start_cpu()

* Borislav Petkov <bp@alien8.de> wrote:

> From: Borislav Petkov <bp@suse.de>
>
> It doesn't really start a CPU but does a far jump to C code. So call it
> that. Eliminate the unconditional JMP to it from secondary_startup_64()
> but make the jump to C code piece part of secondary_startup_64()
> instead.
>
> Also, it doesn't need to be a global symbol either so make it a local
> label. One less needlessly global symbol in the symbol table.
>
> No functionality change.
>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> ---
> arch/x86/kernel/head_64.S | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> index b467b14b03eb..ac9d327d2e42 100644
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -269,10 +269,8 @@ ENTRY(secondary_startup_64)
> /* rsi is pointer to real mode structure with interesting info.
> pass it to C */
> movq %rsi, %rdi
> - jmp start_cpu
> -ENDPROC(secondary_startup_64)
>
> -ENTRY(start_cpu)
> +.Ljump_to_C_code:
> /*
> * Jump to run C code and to be on a real kernel address.
> * Since we are running on identity-mapped space we have to jump
> @@ -305,7 +303,7 @@ ENTRY(start_cpu)
> pushq %rax # target address in negative space
> lretq
> .Lafter_lret:
> -ENDPROC(start_cpu)
> +ENDPROC(secondary_startup_64)
>
> #include "verify_cpu.S"
>
> @@ -313,11 +311,11 @@ ENDPROC(start_cpu)
> /*
> * Boot CPU0 entry point. It's called from play_dead(). Everything has been set
> * up already except stack. We just set up stack here. Then call
> - * start_secondary() via start_cpu().
> + * start_secondary() via .Ljump_to_C_code.
> */
> ENTRY(start_cpu0)
> movq initial_stack(%rip), %rsp
> - jmp start_cpu
> + jmp .Ljump_to_C_code
> ENDPROC(start_cpu0)
> #endif

Wouldn't this be slightly more readable:

jmp .L_jump_to_C_code

? (Note the extra underscore in the symbol name)

The local labels syntax is silly, I always end up looking twice to make sense of
'Ljump' or 'Lwhatever' ;-)

We cannot do anything about that - but we can name our symbols to work it around.
But the price is the extra underscore in the symbol name...

Thanks,

Ingo

\
 
 \ /
  Last update: 2017-03-07 10:07    [W:0.084 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site