Messages in this thread | | | Date | Tue, 6 Feb 2018 12:52:34 +0000 (UTC) | From | Mathieu Desnoyers <> | Subject | Re: linux-next: manual merge of the tip tree with Linus' tree |
| |
----- On Feb 5, 2018, at 7:40 PM, Stephen Rothwell sfr@canb.auug.org.au wrote:
> Hi all, > > Today's linux-next merge of the tip tree got a conflict in: > > arch/arm64/kernel/entry.S > > between commit: > > 4bf3286d29f3 ("arm64: entry: Hook up entry trampoline to exception vectors") > > from Linus' tree and commit: > > f1e3a12b6543 ("membarrier/arm64: Provide core serializing command") > > from the tip tree. > > I fixed it up (probably not completely - see below) and can carry the > fix as necessary. This is now fixed as far as linux-next is concerned, > but any non trivial conflicts should be mentioned to your upstream > maintainer when your tree is submitted for merging. You may also want > to consider cooperating with the maintainer of the conflicting tree to > minimise any particularly complex conflicts.
The change introduced by 4bf3286d29 "arm64: entry: Hook up entry trampoline to exception vectors" adds a trampoline as mechanism for return:
- eret // return to kernel + +#ifndef CONFIG_UNMAP_KERNEL_AT_EL0 + eret +#else + .if \el == 0 + bne 4f + msr far_el1, x30 + tramp_alias x30, tramp_exit_native + br x30 +4: + tramp_alias x30, tramp_exit_compat + br x30 + .else + eret + .endif +#endif
Which means that with CONFIG_UNMAP_KERNEL_AT_EL0, for return to EL0, the eret is in the trampoline:
.macro tramp_exit, regsize = 64 adr x30, tramp_vectors msr vbar_el1, x30 tramp_unmap_kernel x30 .if \regsize == 64 mrs x30, far_el1 .endif eret .endm
ENTRY(tramp_exit_native) tramp_exit END(tramp_exit_native)
ENTRY(tramp_exit_compat) tramp_exit 32 END(tramp_exit_compat)
One approach I would consider for this is to duplicate this comment and add it just above the "eret" instruction within the macro:
/* * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization * when returning from IPI handler, and when returning to user-space. */
Or perhaps Will has something else in mind ?
Thanks,
Mathieu
> > -- > Cheers, > Stephen Rothwell > > diff --cc arch/arm64/kernel/entry.S > index b34e717d7597,5edde1c2e93e..000000000000 > --- a/arch/arm64/kernel/entry.S > +++ b/arch/arm64/kernel/entry.S > @@@ -324,21 -302,11 +324,25 @@@ alternative_else_nop_endi > ldp x28, x29, [sp, #16 * 14] > ldr lr, [sp, #S_LR] > add sp, sp, #S_FRAME_SIZE // restore sp > + > + .if \el == 0 > +alternative_insn eret, nop, ARM64_UNMAP_KERNEL_AT_EL0 > +#ifdef CONFIG_UNMAP_KERNEL_AT_EL0 > + bne 4f > + msr far_el1, x30 > + tramp_alias x30, tramp_exit_native > + br x30 > +4: > + tramp_alias x30, tramp_exit_compat > + br x30 > +#endif > + .else > + /* > + * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization > + * when returning from IPI handler, and when returning to user-space. > + */ > - eret // return to kernel > + eret > + .endif > .endm > > .macro irq_stack_entry
-- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
| |