Re: [PATCHv4 11/19] arm64: don't reload GPRs after apply_ssbd
On Tue, Jul 10, 2018 at 06:33:18PM +0100, Will Deacon wrote: > On Tue, Jul 10, 2018 at 11:37:24AM +0100, Dave Martin wrote: > > For the kernel, I suggest using a .L prefix so that the generated > > symbols don't bloat the vmlinux symbol table (similar to numbered local > > labels) -- unless you really want the symbols retained. > > > > Having a common prefix for all "unique" assembler symbols may help us > > to avoid namespace collisions, say > > > > .L__asm__foo_\@ > > .L__asm__bar_\@ > > Hmm, yes, and that would allow us to replace the open-coded labels in > our assembler.h macros as well, wouldn't it? Yup. For this patch, I'll rename skip_apply_ssbd\@ to .L__asm_ssbd_skip\@. I'll send another patch (or series) converting our other macros to this scheme. We can either take that with this series, or as subsequent cleanup. Thanks, Mark.
Re: [PATCHv4 11/19] arm64: don't reload GPRs after apply_ssbd
On Tue, Jul 10, 2018 at 06:33:18PM +0100, Will Deacon wrote: > On Tue, Jul 10, 2018 at 11:37:24AM +0100, Dave Martin wrote: > > For the kernel, I suggest using a .L prefix so that the generated > > symbols don't bloat the vmlinux symbol table (similar to numbered local > > labels) -- unless you really want the symbols retained. > > > > Having a common prefix for all "unique" assembler symbols may help us > > to avoid namespace collisions, say > > > > .L__asm__foo_\@ > > .L__asm__bar_\@ > > Hmm, yes, and that would allow us to replace the open-coded labels in > our assembler.h macros as well, wouldn't it? Yup. For this patch, I'll rename skip_apply_ssbd\@ to .L__asm_ssbd_skip\@. I'll send another patch (or series) converting our other macros to this scheme. We can either take that with this series, or as subsequent cleanup. Thanks, Mark.
Re: [PATCHv4 11/19] arm64: don't reload GPRs after apply_ssbd
On Tue, Jul 10, 2018 at 11:37:24AM +0100, Dave Martin wrote: > On Mon, Jul 09, 2018 at 03:21:59PM +0100, Mark Rutland wrote: > > On Fri, Jul 06, 2018 at 05:38:45PM +0100, Will Deacon wrote: > > > On Mon, Jul 02, 2018 at 12:04:07PM +0100, Mark Rutland wrote: > > > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > > > > index c41b84d06644..728bc7cc5bbb 100644 > > > > --- a/arch/arm64/kernel/entry.S > > > > +++ b/arch/arm64/kernel/entry.S > > > > @@ -130,20 +130,21 @@ alternative_else_nop_endif > > > > > > > > // This macro corrupts x0-x3. It is the caller's duty > > > > // to save/restore them if required. > > > > - .macro apply_ssbd, state, targ, tmp1, tmp2 > > > > + .macro apply_ssbd, state, tmp1, tmp2 > > > > #ifdef CONFIG_ARM64_SSBD > > > > alternative_cb arm64_enable_wa2_handling > > > > - b \targ > > > > + b skip_apply_ssbd\@ > > > > alternative_cb_end > > > > ldr_this_cpu\tmp2, arm64_ssbd_callback_required, \tmp1 > > > > - cbz \tmp2, \targ > > > > + cbz \tmp2, skip_apply_ssbd\@ > > > > ldr \tmp2, [tsk, #TSK_TI_FLAGS] > > > > - tbnz\tmp2, #TIF_SSBD, \targ > > > > + tbnz\tmp2, #TIF_SSBD, skip_apply_ssbd\@ > > > > > > Talking to Dave, he makes a good point that this is pretty fragile if a > > > macro expansion within the macro itself uses \@, since this would result > > > in an unexpected label update and everything would go wrong. > > > > I don't believe that's a problem; \@ is handled as-if it's a named > > argument to the macro, and is not incremented within the scope of a > > single macro expansion. > > From > https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/macro.c > https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/read.c > > it looks like the \@ counter (macro_number) is only incremented at the > end expansion of a whole macro body before gas reads the expansion > output (including recursive macro expansions). > > So, your conclusion looks right for gas today. The code implementing > this looks crufty enough to be pretty old. > > Can you throw a bug into https://sourceware.org/bugzilla/ to get this > properly documented? The current wording is ambiguous. It would be > nice to get gas properly committed to behaving this way. > > > For the kernel, I suggest using a .L prefix so that the generated > symbols don't bloat the vmlinux symbol table (similar to numbered local > labels) -- unless you really want the symbols retained. > > Having a common prefix for all "unique" assembler symbols may help us > to avoid namespace collisions, say > > .L__asm__foo_\@ > .L__asm__bar_\@ Hmm, yes, and that would allow us to replace the open-coded labels in our assembler.h macros as well, wouldn't it? Will
Re: [PATCHv4 11/19] arm64: don't reload GPRs after apply_ssbd
On Tue, Jul 10, 2018 at 11:37:24AM +0100, Dave Martin wrote: > On Mon, Jul 09, 2018 at 03:21:59PM +0100, Mark Rutland wrote: > > On Fri, Jul 06, 2018 at 05:38:45PM +0100, Will Deacon wrote: > > > On Mon, Jul 02, 2018 at 12:04:07PM +0100, Mark Rutland wrote: > > > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > > > > index c41b84d06644..728bc7cc5bbb 100644 > > > > --- a/arch/arm64/kernel/entry.S > > > > +++ b/arch/arm64/kernel/entry.S > > > > @@ -130,20 +130,21 @@ alternative_else_nop_endif > > > > > > > > // This macro corrupts x0-x3. It is the caller's duty > > > > // to save/restore them if required. > > > > - .macro apply_ssbd, state, targ, tmp1, tmp2 > > > > + .macro apply_ssbd, state, tmp1, tmp2 > > > > #ifdef CONFIG_ARM64_SSBD > > > > alternative_cb arm64_enable_wa2_handling > > > > - b \targ > > > > + b skip_apply_ssbd\@ > > > > alternative_cb_end > > > > ldr_this_cpu\tmp2, arm64_ssbd_callback_required, \tmp1 > > > > - cbz \tmp2, \targ > > > > + cbz \tmp2, skip_apply_ssbd\@ > > > > ldr \tmp2, [tsk, #TSK_TI_FLAGS] > > > > - tbnz\tmp2, #TIF_SSBD, \targ > > > > + tbnz\tmp2, #TIF_SSBD, skip_apply_ssbd\@ > > > > > > Talking to Dave, he makes a good point that this is pretty fragile if a > > > macro expansion within the macro itself uses \@, since this would result > > > in an unexpected label update and everything would go wrong. > > > > I don't believe that's a problem; \@ is handled as-if it's a named > > argument to the macro, and is not incremented within the scope of a > > single macro expansion. > > From > https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/macro.c > https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/read.c > > it looks like the \@ counter (macro_number) is only incremented at the > end expansion of a whole macro body before gas reads the expansion > output (including recursive macro expansions). > > So, your conclusion looks right for gas today. The code implementing > this looks crufty enough to be pretty old. > > Can you throw a bug into https://sourceware.org/bugzilla/ to get this > properly documented? The current wording is ambiguous. It would be > nice to get gas properly committed to behaving this way. > > > For the kernel, I suggest using a .L prefix so that the generated > symbols don't bloat the vmlinux symbol table (similar to numbered local > labels) -- unless you really want the symbols retained. > > Having a common prefix for all "unique" assembler symbols may help us > to avoid namespace collisions, say > > .L__asm__foo_\@ > .L__asm__bar_\@ Hmm, yes, and that would allow us to replace the open-coded labels in our assembler.h macros as well, wouldn't it? Will
Re: [PATCHv4 11/19] arm64: don't reload GPRs after apply_ssbd
On Mon, Jul 09, 2018 at 03:21:59PM +0100, Mark Rutland wrote: > On Fri, Jul 06, 2018 at 05:38:45PM +0100, Will Deacon wrote: > > On Mon, Jul 02, 2018 at 12:04:07PM +0100, Mark Rutland wrote: > > > Now that all of the syscall logic works on the saved pt_regs, apply_ssbd > > > can safely corrupt x0-x3 in the entry paths, and we no longer need to > > > restore them. So let's remove the logic doing so. > > > > > > With that logic gone, we can fold the branch target into the macro, so > > > that callers need not deal with this. GAS provides \@, which provides a > > > unique value per macro invocation, which we can use to create a unique > > > label. > > > > > > Signed-off-by: Mark Rutland > > > Acked-by: Marc Zyngier > > > Acked-by: Catalin Marinas > > > Cc: Will Deacon > > > --- > > > arch/arm64/kernel/entry.S | 20 +++- > > > 1 file changed, 7 insertions(+), 13 deletions(-) > > > > > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > > > index c41b84d06644..728bc7cc5bbb 100644 > > > --- a/arch/arm64/kernel/entry.S > > > +++ b/arch/arm64/kernel/entry.S > > > @@ -130,20 +130,21 @@ alternative_else_nop_endif > > > > > > // This macro corrupts x0-x3. It is the caller's duty > > > // to save/restore them if required. > > > - .macro apply_ssbd, state, targ, tmp1, tmp2 > > > + .macro apply_ssbd, state, tmp1, tmp2 > > > #ifdef CONFIG_ARM64_SSBD > > > alternative_cb arm64_enable_wa2_handling > > > - b \targ > > > + b skip_apply_ssbd\@ > > > alternative_cb_end > > > ldr_this_cpu\tmp2, arm64_ssbd_callback_required, \tmp1 > > > - cbz \tmp2, \targ > > > + cbz \tmp2, skip_apply_ssbd\@ > > > ldr \tmp2, [tsk, #TSK_TI_FLAGS] > > > - tbnz\tmp2, #TIF_SSBD, \targ > > > + tbnz\tmp2, #TIF_SSBD, skip_apply_ssbd\@ > > > > Talking to Dave, he makes a good point that this is pretty fragile if a > > macro expansion within the macro itself uses \@, since this would result > > in an unexpected label update and everything would go wrong. > > I don't believe that's a problem; \@ is handled as-if it's a named > argument to the macro, and is not incremented within the scope of a > single macro expansion. From https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/macro.c https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/read.c it looks like the \@ counter (macro_number) is only incremented at the end expansion of a whole macro body before gas reads the expansion output (including recursive macro expansions). So, your conclusion looks right for gas today. The code implementing this looks crufty enough to be pretty old. Can you throw a bug into https://sourceware.org/bugzilla/ to get this properly documented? The current wording is ambiguous. It would be nice to get gas properly committed to behaving this way. For the kernel, I suggest using a .L prefix so that the generated symbols don't bloat the vmlinux symbol table (similar to numbered local labels) -- unless you really want the symbols retained. Having a common prefix for all "unique" assembler symbols may help us to avoid namespace collisions, say .L__asm__foo_\@ .L__asm__bar_\@ etc. Cheers ---Dave > > e.g. if I assemble: > > > .macro nop_macro > .endm > > .macro a n > a_pre_\n\()_\@: > .quad 0 > a_post_\n\()_\@: > .quad 0 > .endm > > .macro b n > b_pre_\n\()_\@: > .quad 0 > > a \n > > b_post_\n\()_\@: > .quad 0 > .endm > > .macro c n > c_pre_\n\()_\@: > .quad 0 > > b \n > > c_post_\n\()_\@: > .quad 0 > .endm > > .data > > a 0 > > b 1 > > c 2 > > > ... then objdump -D gives me: > > > Disassembly of section .data: > > : > ... > > 0008 : > ... > > 0010 : > ... > > 0018 : > ... > > 0020 : > ... > > 0028 : > ... > > 0030 : > ... > > 0038 : > ... > > 0040 : > ... > > 0048 : > ... > > 0050 : > ... > > 0058 : > ... > > > > ... where things are obviously nesting just fine. > > Thanks, > Mark.
Re: [PATCHv4 11/19] arm64: don't reload GPRs after apply_ssbd
On Mon, Jul 09, 2018 at 03:21:59PM +0100, Mark Rutland wrote: > On Fri, Jul 06, 2018 at 05:38:45PM +0100, Will Deacon wrote: > > On Mon, Jul 02, 2018 at 12:04:07PM +0100, Mark Rutland wrote: > > > Now that all of the syscall logic works on the saved pt_regs, apply_ssbd > > > can safely corrupt x0-x3 in the entry paths, and we no longer need to > > > restore them. So let's remove the logic doing so. > > > > > > With that logic gone, we can fold the branch target into the macro, so > > > that callers need not deal with this. GAS provides \@, which provides a > > > unique value per macro invocation, which we can use to create a unique > > > label. > > > > > > Signed-off-by: Mark Rutland > > > Acked-by: Marc Zyngier > > > Acked-by: Catalin Marinas > > > Cc: Will Deacon > > > --- > > > arch/arm64/kernel/entry.S | 20 +++- > > > 1 file changed, 7 insertions(+), 13 deletions(-) > > > > > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > > > index c41b84d06644..728bc7cc5bbb 100644 > > > --- a/arch/arm64/kernel/entry.S > > > +++ b/arch/arm64/kernel/entry.S > > > @@ -130,20 +130,21 @@ alternative_else_nop_endif > > > > > > // This macro corrupts x0-x3. It is the caller's duty > > > // to save/restore them if required. > > > - .macro apply_ssbd, state, targ, tmp1, tmp2 > > > + .macro apply_ssbd, state, tmp1, tmp2 > > > #ifdef CONFIG_ARM64_SSBD > > > alternative_cb arm64_enable_wa2_handling > > > - b \targ > > > + b skip_apply_ssbd\@ > > > alternative_cb_end > > > ldr_this_cpu\tmp2, arm64_ssbd_callback_required, \tmp1 > > > - cbz \tmp2, \targ > > > + cbz \tmp2, skip_apply_ssbd\@ > > > ldr \tmp2, [tsk, #TSK_TI_FLAGS] > > > - tbnz\tmp2, #TIF_SSBD, \targ > > > + tbnz\tmp2, #TIF_SSBD, skip_apply_ssbd\@ > > > > Talking to Dave, he makes a good point that this is pretty fragile if a > > macro expansion within the macro itself uses \@, since this would result > > in an unexpected label update and everything would go wrong. > > I don't believe that's a problem; \@ is handled as-if it's a named > argument to the macro, and is not incremented within the scope of a > single macro expansion. From https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/macro.c https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/read.c it looks like the \@ counter (macro_number) is only incremented at the end expansion of a whole macro body before gas reads the expansion output (including recursive macro expansions). So, your conclusion looks right for gas today. The code implementing this looks crufty enough to be pretty old. Can you throw a bug into https://sourceware.org/bugzilla/ to get this properly documented? The current wording is ambiguous. It would be nice to get gas properly committed to behaving this way. For the kernel, I suggest using a .L prefix so that the generated symbols don't bloat the vmlinux symbol table (similar to numbered local labels) -- unless you really want the symbols retained. Having a common prefix for all "unique" assembler symbols may help us to avoid namespace collisions, say .L__asm__foo_\@ .L__asm__bar_\@ etc. Cheers ---Dave > > e.g. if I assemble: > > > .macro nop_macro > .endm > > .macro a n > a_pre_\n\()_\@: > .quad 0 > a_post_\n\()_\@: > .quad 0 > .endm > > .macro b n > b_pre_\n\()_\@: > .quad 0 > > a \n > > b_post_\n\()_\@: > .quad 0 > .endm > > .macro c n > c_pre_\n\()_\@: > .quad 0 > > b \n > > c_post_\n\()_\@: > .quad 0 > .endm > > .data > > a 0 > > b 1 > > c 2 > > > ... then objdump -D gives me: > > > Disassembly of section .data: > > : > ... > > 0008 : > ... > > 0010 : > ... > > 0018 : > ... > > 0020 : > ... > > 0028 : > ... > > 0030 : > ... > > 0038 : > ... > > 0040 : > ... > > 0048 : > ... > > 0050 : > ... > > 0058 : > ... > > > > ... where things are obviously nesting just fine. > > Thanks, > Mark.
Re: [PATCHv4 11/19] arm64: don't reload GPRs after apply_ssbd
On Fri, Jul 06, 2018 at 05:38:45PM +0100, Will Deacon wrote: > On Mon, Jul 02, 2018 at 12:04:07PM +0100, Mark Rutland wrote: > > Now that all of the syscall logic works on the saved pt_regs, apply_ssbd > > can safely corrupt x0-x3 in the entry paths, and we no longer need to > > restore them. So let's remove the logic doing so. > > > > With that logic gone, we can fold the branch target into the macro, so > > that callers need not deal with this. GAS provides \@, which provides a > > unique value per macro invocation, which we can use to create a unique > > label. > > > > Signed-off-by: Mark Rutland > > Acked-by: Marc Zyngier > > Acked-by: Catalin Marinas > > Cc: Will Deacon > > --- > > arch/arm64/kernel/entry.S | 20 +++- > > 1 file changed, 7 insertions(+), 13 deletions(-) > > > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > > index c41b84d06644..728bc7cc5bbb 100644 > > --- a/arch/arm64/kernel/entry.S > > +++ b/arch/arm64/kernel/entry.S > > @@ -130,20 +130,21 @@ alternative_else_nop_endif > > > > // This macro corrupts x0-x3. It is the caller's duty > > // to save/restore them if required. > > - .macro apply_ssbd, state, targ, tmp1, tmp2 > > + .macro apply_ssbd, state, tmp1, tmp2 > > #ifdef CONFIG_ARM64_SSBD > > alternative_cb arm64_enable_wa2_handling > > - b \targ > > + b skip_apply_ssbd\@ > > alternative_cb_end > > ldr_this_cpu\tmp2, arm64_ssbd_callback_required, \tmp1 > > - cbz \tmp2, \targ > > + cbz \tmp2, skip_apply_ssbd\@ > > ldr \tmp2, [tsk, #TSK_TI_FLAGS] > > - tbnz\tmp2, #TIF_SSBD, \targ > > + tbnz\tmp2, #TIF_SSBD, skip_apply_ssbd\@ > > Talking to Dave, he makes a good point that this is pretty fragile if a > macro expansion within the macro itself uses \@, since this would result > in an unexpected label update and everything would go wrong. I don't believe that's a problem; \@ is handled as-if it's a named argument to the macro, and is not incremented within the scope of a single macro expansion. e.g. if I assemble: .macro nop_macro .endm .macro a n a_pre_\n\()_\@: .quad 0 a_post_\n\()_\@: .quad 0 .endm .macro b n b_pre_\n\()_\@: .quad 0 a \n b_post_\n\()_\@: .quad 0 .endm .macro c n c_pre_\n\()_\@: .quad 0 b \n c_post_\n\()_\@: .quad 0 .endm .data a 0 b 1 c 2 ... then objdump -D gives me: Disassembly of section .data: : ... 0008 : ... 0010 : ... 0018 : ... 0020 : ... 0028 : ... 0030 : ... 0038 : ... 0040 : ... 0048 : ... 0050 : ... 0058 : ... ... where things are obviously nesting just fine. Thanks, Mark.
Re: [PATCHv4 11/19] arm64: don't reload GPRs after apply_ssbd
On Fri, Jul 06, 2018 at 05:38:45PM +0100, Will Deacon wrote: > On Mon, Jul 02, 2018 at 12:04:07PM +0100, Mark Rutland wrote: > > Now that all of the syscall logic works on the saved pt_regs, apply_ssbd > > can safely corrupt x0-x3 in the entry paths, and we no longer need to > > restore them. So let's remove the logic doing so. > > > > With that logic gone, we can fold the branch target into the macro, so > > that callers need not deal with this. GAS provides \@, which provides a > > unique value per macro invocation, which we can use to create a unique > > label. > > > > Signed-off-by: Mark Rutland > > Acked-by: Marc Zyngier > > Acked-by: Catalin Marinas > > Cc: Will Deacon > > --- > > arch/arm64/kernel/entry.S | 20 +++- > > 1 file changed, 7 insertions(+), 13 deletions(-) > > > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > > index c41b84d06644..728bc7cc5bbb 100644 > > --- a/arch/arm64/kernel/entry.S > > +++ b/arch/arm64/kernel/entry.S > > @@ -130,20 +130,21 @@ alternative_else_nop_endif > > > > // This macro corrupts x0-x3. It is the caller's duty > > // to save/restore them if required. > > - .macro apply_ssbd, state, targ, tmp1, tmp2 > > + .macro apply_ssbd, state, tmp1, tmp2 > > #ifdef CONFIG_ARM64_SSBD > > alternative_cb arm64_enable_wa2_handling > > - b \targ > > + b skip_apply_ssbd\@ > > alternative_cb_end > > ldr_this_cpu\tmp2, arm64_ssbd_callback_required, \tmp1 > > - cbz \tmp2, \targ > > + cbz \tmp2, skip_apply_ssbd\@ > > ldr \tmp2, [tsk, #TSK_TI_FLAGS] > > - tbnz\tmp2, #TIF_SSBD, \targ > > + tbnz\tmp2, #TIF_SSBD, skip_apply_ssbd\@ > > Talking to Dave, he makes a good point that this is pretty fragile if a > macro expansion within the macro itself uses \@, since this would result > in an unexpected label update and everything would go wrong. I don't believe that's a problem; \@ is handled as-if it's a named argument to the macro, and is not incremented within the scope of a single macro expansion. e.g. if I assemble: .macro nop_macro .endm .macro a n a_pre_\n\()_\@: .quad 0 a_post_\n\()_\@: .quad 0 .endm .macro b n b_pre_\n\()_\@: .quad 0 a \n b_post_\n\()_\@: .quad 0 .endm .macro c n c_pre_\n\()_\@: .quad 0 b \n c_post_\n\()_\@: .quad 0 .endm .data a 0 b 1 c 2 ... then objdump -D gives me: Disassembly of section .data: : ... 0008 : ... 0010 : ... 0018 : ... 0020 : ... 0028 : ... 0030 : ... 0038 : ... 0040 : ... 0048 : ... 0050 : ... 0058 : ... ... where things are obviously nesting just fine. Thanks, Mark.
Re: [PATCHv4 11/19] arm64: don't reload GPRs after apply_ssbd
On Mon, Jul 02, 2018 at 12:04:07PM +0100, Mark Rutland wrote: > Now that all of the syscall logic works on the saved pt_regs, apply_ssbd > can safely corrupt x0-x3 in the entry paths, and we no longer need to > restore them. So let's remove the logic doing so. > > With that logic gone, we can fold the branch target into the macro, so > that callers need not deal with this. GAS provides \@, which provides a > unique value per macro invocation, which we can use to create a unique > label. > > Signed-off-by: Mark Rutland > Acked-by: Marc Zyngier > Acked-by: Catalin Marinas > Cc: Will Deacon > --- > arch/arm64/kernel/entry.S | 20 +++- > 1 file changed, 7 insertions(+), 13 deletions(-) > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > index c41b84d06644..728bc7cc5bbb 100644 > --- a/arch/arm64/kernel/entry.S > +++ b/arch/arm64/kernel/entry.S > @@ -130,20 +130,21 @@ alternative_else_nop_endif > > // This macro corrupts x0-x3. It is the caller's duty > // to save/restore them if required. > - .macro apply_ssbd, state, targ, tmp1, tmp2 > + .macro apply_ssbd, state, tmp1, tmp2 > #ifdef CONFIG_ARM64_SSBD > alternative_cb arm64_enable_wa2_handling > - b \targ > + b skip_apply_ssbd\@ > alternative_cb_end > ldr_this_cpu\tmp2, arm64_ssbd_callback_required, \tmp1 > - cbz \tmp2, \targ > + cbz \tmp2, skip_apply_ssbd\@ > ldr \tmp2, [tsk, #TSK_TI_FLAGS] > - tbnz\tmp2, #TIF_SSBD, \targ > + tbnz\tmp2, #TIF_SSBD, skip_apply_ssbd\@ Talking to Dave, he makes a good point that this is pretty fragile if a macro expansion within the macro itself uses \@, since this would result in an unexpected label update and everything would go wrong. Can you default initialise an extra label argument to \@, or does that not work? Will
Re: [PATCHv4 11/19] arm64: don't reload GPRs after apply_ssbd
On Mon, Jul 02, 2018 at 12:04:07PM +0100, Mark Rutland wrote: > Now that all of the syscall logic works on the saved pt_regs, apply_ssbd > can safely corrupt x0-x3 in the entry paths, and we no longer need to > restore them. So let's remove the logic doing so. > > With that logic gone, we can fold the branch target into the macro, so > that callers need not deal with this. GAS provides \@, which provides a > unique value per macro invocation, which we can use to create a unique > label. > > Signed-off-by: Mark Rutland > Acked-by: Marc Zyngier > Acked-by: Catalin Marinas > Cc: Will Deacon > --- > arch/arm64/kernel/entry.S | 20 +++- > 1 file changed, 7 insertions(+), 13 deletions(-) > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > index c41b84d06644..728bc7cc5bbb 100644 > --- a/arch/arm64/kernel/entry.S > +++ b/arch/arm64/kernel/entry.S > @@ -130,20 +130,21 @@ alternative_else_nop_endif > > // This macro corrupts x0-x3. It is the caller's duty > // to save/restore them if required. > - .macro apply_ssbd, state, targ, tmp1, tmp2 > + .macro apply_ssbd, state, tmp1, tmp2 > #ifdef CONFIG_ARM64_SSBD > alternative_cb arm64_enable_wa2_handling > - b \targ > + b skip_apply_ssbd\@ > alternative_cb_end > ldr_this_cpu\tmp2, arm64_ssbd_callback_required, \tmp1 > - cbz \tmp2, \targ > + cbz \tmp2, skip_apply_ssbd\@ > ldr \tmp2, [tsk, #TSK_TI_FLAGS] > - tbnz\tmp2, #TIF_SSBD, \targ > + tbnz\tmp2, #TIF_SSBD, skip_apply_ssbd\@ Talking to Dave, he makes a good point that this is pretty fragile if a macro expansion within the macro itself uses \@, since this would result in an unexpected label update and everything would go wrong. Can you default initialise an extra label argument to \@, or does that not work? Will
